Date: Thu, 01 Mar 2001 22:11:38 -0400 From: "Jeroen C. van Gelderen" <jeroen@vangelderen.org> To: Nate Williams <nate@yogotech.com> Cc: FreeBSD Java <freebsd-java@FreeBSD.ORG>, Ari Suutari <ari@suutari.iki.fi> Subject: Re: Are syscall wrappers needed in JNI? Message-ID: <3A9F015A.CE487843@vangelderen.org> References: <3A9AE85F.C6F06D96@vangelderen.org> <15002.60084.89087.467979@nomad.yogotech.com> <3A9EF71F.A13189C6@vangelderen.org> <15006.63617.145790.5705@nomad.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Man, thanks for those instant responses! :-) Nate Williams wrote: > > > Sorry for the delay in response but I've been busy hacking > > JNI :-( > > > > Nate Williams wrote: > > > > > > > So... I'm hoping that someone here has the magic knowledge in > > > > his/her brain... How does one properly use libc from within Java? > > > > > > You can't in the current JDK1.1 stuff. > > > > I take it you meant to say JDK 1.2 beta as well? Or not? > > Since it also uses green threads, then it has the same limitations. Allright, that's what I assumed... What I don't understand is that Ari says it can actually work whereas you seem to indicate that calling libc functions cannot be done until we get pthreads going... Are the two of you perhaps saying that one can call only those libc functions that are also used by the JDK and therefore exported from libhpi.so in wrapped form? (This interpretation seems to agree with an nm libhpi.so in that nm reveals an export for poll but not one for select which would explain Ari's problems using poll.) If the answer is yes I am happy because it means that my UNIX domain socket project is feasible because all the calls I need for UNIX socket support are already used by the JVM for it's java.net.(Server)Socket implemtation (read/write/accept/...). In any case I think I have found a safe approach that involves calling the various JVM_* functions in libjava.so on the assumption that those are simple wrappers for the actual syscalls. Calling JVM_* functions has the advantage that one's program will not silently call libc functions directly when a wrapped version is not available. I.e. calling JVM_Bind will fail to link becayse JVM_Bind doesn't exist but calling plain bind would silently link to the libc version and maybe cause problems later on. (This is just an example, bind actually is safe to call directly, see next paragraph.) At any rate, it seems that wrappers are only neccessary for those syscalls that can block. The bind call for example is safe without a wrapper (as evidenced by the java.net JNI implementation). [...] > Interesting enough, from my memory, select is wrapped in the JVM, but > poll was not. My suspicion is that the wrapping was causing problems, > and his modification to use 'poll' caused it to call the native poll, > instead of the wrapped 'select' version, which can cause problems. The other way around. He called select which failed but everything was fine after he switched to using poll which is wrapped in the current JDK. Cheers, Jeroen PS. The code in question will be released when finished btw. -- Jeroen C. van Gelderen - jeroen@vangelderen.org "If I could save the Union without freeing any slave I would do it; and if I could save it by freeing some and leaving others alone I would also do that." -- Abraham Lincoln, August 22, 1862 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A9F015A.CE487843>