> > Consider a 'select' followed by a 'read' in another thread. Is > > that the operation that shouldn't block or are the 'select' and > > the 'read' unrelated?
> If the read was started (called) after the select finished > (returned), then this read (and only this read) is the subsequent > operation. If two threads invoke reads concurrently, there is no > way for the threads to determine which read will block and which > will not block, so the program should not do so. I've explained why this doesn't work at least three times now and you still don't understand it. I'm not sure what else I can do. Please read over my example again where you try to do the same thing with 'write' and the implementation can't tell whether a particular 'write' is supposed to have normal blocking semantics or special "subsequent operation" non-blocking semantics. > > Data won't arrive until you call 'read'. And 'read' is blocking > > on NFS files normally. You'd need a non-blocking read, followed > > by 'select', followed perhaps by repeating the 'read'. > Wouldn't this mean, that select would not work as specified and thus > would be a bug? Maybe I'll play with select on a NFS file when > I'd get some time. Could become surprising after that what I > learned now... :) Typical 'select' documentation says that a regular file is always ready for reading and writing. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
