Cesard, Patrick O. wrote: > Hello, > > If I were to use the PR_FileDesc2NativeHandle function to get to the actual > fd of a NSPR socket, and then used this fd in a select or poll call (non > NSPR calls) to do multiplexing of I/O, should any consideration be given to > whether the NSPR socket is a SSL layered socket or a plain NSPR socket? > > In other words, Julien Pierre said at one point (this discussion originally > started in the mozilla.nspr newsgroup): "If it's an NSS socket doing SSL, > the fact that there is data on it doesn't necessarily mean that it's > application data. You should only read from that socket with NSPR functions, > never OS functions...".
What I meant by the above is that the incoming socket data that's been detected might be data for the SSL handshake. Obviously you can't process that with a native recv() or read() call, or you will get garbage. You must use PR_Recv() or PR_Read(). > So the better question is then: if my application uses NSS sockets doing > SSL, and at some point I get the corresponding native fd as described above, > use it in a select call, and the latter detects I/O on the fd, can I safely > then call PR_Read on the original NSS socket? You should use PR_Recv() for this case, not PR_Read(). If the incoming data is only handshake data but the peer didn't send any application data, a PR_Read() will block your thread until there is application data actually available from the peer. So you should call PR_Recv() with a timeout of zero instead. This may return no data and seemingly do nothing from your application point of view, but underneath it will in fact consume the SSL handshake data to continue the handshake processing. Similar logic may be needed for other types of (non-SSL) NSPR layering that you can define yourself, which may use headers that are discarded in the layer and never passed to the application. In that case, just like SSL, there is socket data but not necessarily application data. -- "Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too." Linux-Kernel archive
