I guess that the sigtimedwait() is making timeout less than 2 msec or so.
This can cause trouble for the GC because it is low priority thread. And your
thread is probably using all the processer cycles.
You will get into the trouble with Green Threads. Sure. I think you should
probably have a Thread T that works with an object A synchronized method,
say dispatch() that calls wait(). With A have another synchronized method
call proceed() on a notify(). What you will have to do is probably use
a collection like LinkedList , ArrayList, or anything that implements a Queue FIFO
and simple add EventObject to the collection.
You can do this through JNI and therefore thru sigtimedwait().
When you add the new event call proceed(). The dispatch thread T
wakes up remove the next event from the queue() and calls the Java listener.
Hope this makes sense.
--
Peter Pilgrim
"Putting PLEASE HELP ME! URGENT HELP! in the E-Mail Subject: Line,
will probably lead to the opposite intention." << The Windows Trash Can >>
---------------------------------------- Message History
----------------------------------------
From: Christopher Smith <[EMAIL PROTECTED]> on 29/05/2001 13:59 MST
To: [EMAIL PROTECTED]
cc:
Subject: Signals, JNI and sigtimedwait()...
Okay, I'm writing some JNI code for some stuff using RT signals. I need to
do some sigtimedwaits, which then post as IO events to the JVM. My original
design was to have Java threads invoke something like waitForIO(), which
was a native method which did the sigtimedwait(). Unfortunately, this seems
like to cause problems for the JVM's GC.
Is the only solution to use native threads, have them "join" the VM to post
events, and then have them "leave" the VM before invoking sigtimedwait()
again? That seems just really slow and painful.
--Chris
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorised copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]