[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Running ControlExample exampleprogramfailsunderHP-UX
|
Thanks! you were correct. It fails...
Never realized it.
(Its strange, why does not it complain? Oh! well..)
-Sri
Silenio_Quarti@xxxxxxx wrote:
> Just calling XInitThreads() in the C program is not enough to make
> the executable multi-threaded. You need to link the program with
> pthreads. Something like:
>
> cc -o test main.c -lXm -lXt -lX11 -lpthread
>
> Silenio
>
> Sridhar Bidigalu <sridhar@xxxxxxx>
> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
> 03/08/02 03:22 PM
> Please respond to platform-swt-dev
>
>
> To: platform-swt-dev@xxxxxxxxxxx
> cc:
> Subject: Re: [platform-swt-dev] Running ControlExample
> exampleprogramfailsunderHP-UX
>
>
> Steve,
> I had tried using it in the C program, it works. It fails only
> when using it within Java class. I believe it is the weird JAVA
> thing:(
> -Sri
> Steve_Northover@xxxxxxx wrote:
>
> Sridhar,
> Could you try the following. Add the XInitThread to the example Java code
> I sent you (the code you translated into C) and determine that this fails.
> Also,
> try adding it to the C code you translated. Both should fail.
> <rant>
> The whole "XInitThreads" thing is something that the X (Unix?) community
> should be
> ashamed of. This is the official, sanctioned API to do multi-threaded X
> programming
> on Linux, AIX and Solaris (and now HP) and it doesn't work for
> international programming,
> with drag and drop, printing ... and now XFillPolygon. What this means is
> there are no
> interesting multi-threaded applications or stated another way, every
> comprehensive
> application (like Eclipse or Netscape) must implement their own locking.
> This code
> is not trivial, especially getting it right with respect to the event
> loop. Sheesh!
> Now, you and I may hate Windows but when they introduced threads from 3.11
> to 95,
> the international support continued to work, the printing continued to
> work, the drag
> and drop continued to work ...
> </rant>
> I'm sorry about the <rant> but I just need to sound off somewhere.
> Steve
>
>
>
>
> Carolyn_MacLeod@xxxxxxx
> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
> 03/08/02 10:29 AM
> Please respond to platform-swt-dev
>
> To: platform-swt-dev@xxxxxxxxxxx
> cc:
> Subject: Re: [platform-swt-dev] Running ControlExample
> exampleprogramfailsunderHP-UX
> Sridhar,
> We removed the call to XInitThreads and replaced it with our own thread
> locking mechanism.
> I believe we did this in about the middle of February.
> We did it because we had an unbelievable number of problems with
> XInitThreads: hangs in drag & drop, printing, and using the IME.
> Please try the latest drop of eclipse (I am currently running 20020305,
> and it is basically fine - only a few unimportant annoyances <g>).
> Let us know if your polygon draws using the latest SWT code.
> Carolyn
>
>
>
>
> Sridhar Bidigalu <sridhar@xxxxxxx>
> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
> 03/08/2002 09:43 AM
> Please respond to platform-swt-dev
>
> To: platform-swt-dev@xxxxxxxxxxx
> cc:
> Subject: Re: [platform-swt-dev] Running ControlExample
> exampleprogramfailsunderHP-UX
>
> Guys,
> I traced thru. the SWT code and the problem occurs in XInitThreads.
> I was running the stable build drop 200020125. And it, does use
> the XInitThreads. Since, I had no clue about the SWT code, I did
> not know, where to look for the XInitThreads and when I traced thru.
> the program, I saw it get initialized at Display class of SWT. I created
> my own JNI method, where it creates a shell calling X, Xt
> directly(which uses XFillPolygon) and provided calling this method
> within SWT code, until I reached where it stopped drawing XFillPolygon.
> And, it failed to draw after calling XInitThreads.
> Does this mean I can take out calling XInitThreads? and everything should
> work fine. Can anyone tell why it use to fail calling XinitThreads?
> Thanks
> -Sri
> Mike_Wilson@xxxxxxx wrote:
> > I hope, everyone do agree that the problem is isolated
> > to SWT code and some kind of memory corruption is going
> > on, correct?
> Sridhar,
> The problem is that, perfectly reasonable, working SWT code that
> runs on several versions of linux, as well as Solaris, is failing because
> of an incompatibility between that code and the HP-UX implementation of
> X/Motif. I _do_not_ believe that memory corruption is the problem,
> although I _do_ believe it's probably the *symptom* you are seeing.
> Basically, you need to look at all the native calls which are
> occurring in the "high level" example James sent, and compare them against
>
> the ones in the "low level Java PI" version. If there are any calls which
> show up in the high level one which are not in the low level one, then
> they are possible problem sites. For the calls which show up in both, make
>
> sure the arguments are reasonable in both. If you have not got a debugger
> that you can use for this, then you will need to add printfs, etc. If
> you've got a JVMDI compatible VM, then you should be able to use the
> remote debugging support in Eclipse to help you.
> The most obvious places where there could be problems are:
> - differences in expected arguments/return values between
> HP-UX Motif and, the other Motifs.
> - new endian problems which we haven't seen yet (although
> this would be somewhat odd, since we do run on at least one big-endian
> platform)
> - type size differences
> - type layout differences
> If, for example, you find a place where a bogus argument is being
> passed to one of the natives, then you need to trace back through the code
>
> to find out where it was created.
> Really, there's not a lot more I can say though, You actually have
> the best possible situation you could expect to have when porting. You
> have two very small examples which should be doing the same thing but
> aren't. You're just going to have to work through them.
> I wish I could be more helpful,
> McQ.
>
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
