Andrew Haley wrote: > > I wrote an implementation of Runtime.exec() (including a new class > > java.lang.VMProcess which extends java.lang.Process and native code) > > for JC. This can be easily merged into Classpath if people want it. > > It seems like a pretty glaring omission. > > > > This uses the usual Unix functions of fork(), exec(), waitpid(), etc. > > and should be as portable as the existing native code. I'd have to > > rewrite my JCNI native code in JNI but that would be easy. > > > > Let me know if people are interested. > > This sounds good. However, the precise implementation of this class > is very delicate and error-prone, and we found a number of bugs in > gcj's implementation. The trouble is that our bugs were only noticed > after some time. I guess you may write fewer bugs than we did, but > there still might be one or two in yours. :-)
I'm certain there are bugs in mine :-) I just implemented things in the "obvious" way. > Would you be interested in having a look at the libgcj implementation > and comparing? Rather than having to download or check out all of > libgcj, I could just send you the few files. Yes, please do send me the files as I'd be interested to see them. One thing I noticed is that waitFor() can throw InterruptedException, which to me implies that they are implementing it via Object.wait() or Thread.join(). For example, creating a new thread to fork() and then waitpid() on each process would be heavyweight but might work well. Then you just join() the thread in waitFor(), plus problem #2 goes away. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
