Guilhem Lavaux wrote: > Casey Marshall wrote: >> Guilhem Lavaux wrote: >>> In respect to this buggy interface, it is ok. :) >>> >> I fail to see why this is buggy. >> > > Ok. > > 1) POSIX syscalls where originally written with no threads in mind. > glibc uses a trick to store errno in a thread local storage using a > special function. So the expected behaviour of storing errno just after > the accept is true only in this case. If you use other type of threaded > system then it may not be right (or for example if the library is buggy). > Point. I said this on IRC, too, but I think the goal here should be to make it work on Linux first, then systems about as capable as Linux, then for the unwashed masses. If we need to use a thread-safe alternative to using errno directly, we can add that. > 2) cpnio_* interface is duplicating the implementation of native-lib by > abstracting some other syscalls. This is a bit burdensome because it is > done in one library which is not really advertised as "PLEASE > REIMPLEMENT THIS IF YOU ARE NOT USING A USUAL POSIX SYSTEM LIKE LINUX". > Point. This is really because I did the VMChannel work mostly before the native-lib changes were checked in; the cpnio functions were really meant to be a way for VMs to replace *blocking* syscalls. Ie, I don't expect that a VM implementor would need -- or want -- to re-implement every single POSIX call used by Classpath. The blocking-vs-non-blocking thing partly comes from some of the comments by the JikesRVM guys, and partly from reading man pages. If the split made here isn't correct, then we can address that. cpnio is more a "re-implement this if you are stuck with a user thread library, but otherwise are using POSIX." > 3) I am looking a bit at VMChannel.c and cpnio.c and there are some > discrepency I see: somebody has created an interface for some syscalls > but not some other. A VM implementor could not intercept all these calls > easily and would end to add hooks in VMChannel.c (so to reimplement it). > I mention the reason for this above. On the whole, it doesn't seem at all valuable to have a completely platform-independent native layer, because (1) it's simply hard to write such a beast, (2) using POSIX code is already pretty portable, and (3) that's the point of the VM layer, and we don't need yet another portability layer below that. The VMChannel native code is, I think you'll agree, extremely simple, and deliberately so. I think that maintaining that style throughout Classpath is the best way to do it. > I could think also some strange cases like being able to translate errno > before returning the syscall but you would argue we are dealing with > posix systems (which is not entirely false). > > So, I would rather we use all the same interface (cpnet_* is nearly > correct, maybe we can rename it to cpnio_* and add a few functions). > > Another possibility is that I am wrong in the philosophy that we want to > put in the native implementation of classpath. But we are so near to > have something a bit more general and portable that I cannot stand > saying a few words about the current implementation. > Again, my position is that the VM layer should be good enough for handling platform-specific stuff that can't be addressed within a POSIX-like API. Cheers.
