Casey Marshall wrote: > Guilhem Lavaux wrote: >> Hi Robert, >> >> You are using tmp_errno = errno... ret is precisely holding errno. I > > Nope. 'ret' contains the return value of 'accept', which is not the same > as 'errno'. > >> have built the native-lib so that we are always thread safe. I have not >> noticed that VMChannel is so native-lib agnostic. ;-) I will have to >> rewrite VMChannel... Probably next weeks will be devoted to this. >> > > Why does NIO need to use the native-lib way at all? What, pray tell, is > wrong with the POSIX way of doing things? > > Please don't rewrite VMChannel. If accessing 'errno' is not thread safe > on some platforms (I think on Linux and Darwin it should be thread safe) > then we should work around that. > >> 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). 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". 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 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. Best regards, Guilhem.
