Re: Signals, JNI and sigtimedwait()...
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]
Fwd: Re: Java/Linux at JavaOne
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I meant this to be sent to the mailing list, but I selected "Reply" originally instead of "Reply To All" - -- Forwarded Message -- Subject: Re: Java/Linux at JavaOne Date: Wed, 30 May 2001 21:23:46 +1000 From: Jesus M. Salvo Jr. <[EMAIL PROTECTED]> To: Christopher Smith <[EMAIL PROTECTED]> - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 30 May 2001 16:27, Christopher Smith wrote: > So, the thread issue is a nasty one, particularly if you're say hosting > servlets on Linux. 90% of the reason you need all these threads is due to > the thread-per-IO model in standard Java I/O. Unfortunately, this doesn't > map too efficiently to the 1-1 thread model found in most Linux JVM's. > There are a few strategies for coping with this: > > 1) Use green threads (people don't normally think of this as an OK solution > for an application server) > 2) Have a C or other application multiplex the I/O either over sockets or > JMS. > 3) Use lots of boxes & tweak the kernel to allow as many threads as > possible. > 4) Use JNI to use Linux's various asynch I/O API's. Option 4) is how BEA WebLogic Server does it, ( I think ). They have this libmuxer.so ( which is also available for Solaris -- dont know why when JVM for Solaris makes use of solaris native threads ) which enables native I/O, or the so-called "performance pack". > The good news is Linux's thread model is moving in a direction to better > support Java's approach to I/O (IBM's next generation pthreads > implementation), and Java's approach to I/O (NIO) is moving closer to the > efficient way to do I/O with Linux. Indeed, we're working on some > benchmarks right now for #4 and also using NIO to see just how far Linux > will go. My bet is Linux is actually going to prove very cost-effective in > terms of scalability with this stuff. Speaking of 4), does anyway have a ready-made ( cut&paste ) C code that one can compile into a shared library and have all I/O made through this library via JNI? And how does JDK 1.4 affect the performance on Linux, given that 1.4 was better I/O support overall, in particular non-blocking I/O. > --Chris > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] - -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsU2EUACgkQAvd5SY4qWYzDqACfQPZ3+6d+/aeQZObLPkL7YkdY 1Z8AnjOwJMv0djUbLzWkjARwnEqLvgzI =gsnA - -END PGP SIGNATURE- - --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsVW9gACgkQAvd5SY4qWYyPuQCfXRBxMHYDx/p+ygYHnfGsZqAb bPUAoI0qAXvk0NPRZkLfmh8/j3owoF8P =YWRW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Java/Linux at JavaOne
On 31 May 2001 06:45:08 +1000, Jesus M. Salvo Jr. wrote: > > 4) Use JNI to use Linux's various asynch I/O API's. > Option 4) is how BEA WebLogic Server does it, ( I think ). They have this > libmuxer.so ( which is also available for Solaris -- dont know why when JVM > for Solaris makes use of solaris native threads ) which enables native I/O, > or the so-called "performance pack". Yes, many of the various application servers employ various strategies for this. Unfortunately I am unaware of any of them who have taken the time to do this for Linux. > Speaking of 4), does anyway have a ready-made ( cut&paste ) C code that one > can compile into a shared library and have all I/O made through this library > via JNI? I'll be demoing a library that does this with SGI's KAIO patch at the presentation (presuming I can iron out this nasty sigtimedwait problem). > And how does JDK 1.4 affect the performance on Linux, given that 1.4 was > better I/O support overall, in particular non-blocking I/O. We're benchmarking that right now, but it doesn't take a genius to realize the impact is pretty spectacular. All you need to do is compare Apache's performance with polling I/O based web servers on Linux to get a good idea of the potential performance gains. The NIO API is a little annoying to me though in that it's low enough level that it exposing the polling approach to I/O. With the overhead of JNI, it's much nicer to use an asynch I/O approach for most Java applications. --Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JMF external MIDI support?
Hi, I'm new to this list. I'm just starting to experiment with JMF on Linux, and I haven't found in any documentation whether external MIDI devices are supported. Is this the right place to ask about this? I'm using the ALSA drivers with OSS emulation. ALSA midi players work fine, as do OSS midi players, but JMF does not appear to detect any external MIDI devices. Here's the output of a little program I wrote that prints out the results of MidiSystem.getMidiDeviceInfo(): 0: description=Software wavetable synthesizer and receiver, name=Java Sound Synthesizer, vendor=Sun Microsystems, version=Version 1.0 1: description=Software sequencer / synthesizer module, name=Java Sound Sequencer, vendor=Sun Microsystems, version=Version 1.0 This program detects all the right MIDI devices when I run it on Windows. If I play a MIDI file from jmstudio, it's played using the software synth. So my question is: does JMF for Linux support external MIDI devices (or, more generally, non-software synth MIDI devices)? If so, any tips on getting it to detect the device? If not, I'll probably write a driver for ALSA. Thanks for any help! Versions: alsa-driver-0.5.11 j2sdk-1.3.0-FCS-linux-i386 jmf-for-java2-2.1.1-fcs-linux-i386 linux-2.4.4 Using ALSA's ymfpci driver. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
