Re: [platform-swt-dev] Running ControlExample exampleprogramfailsunder

[Silenio_Quarti@xxxxxxx]

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