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...". 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? -- POC -----Original Message----- From: Wan-Teh Chang [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 08, 2002 10:49 PM To: [EMAIL PROTECTED] Subject: Re: Where in a NSPR socket object is the actual file descriptor (fd)? Patrick wrote: > Where in a NSPR socket object is the actual file descriptor (fd)? The actual fd can be retrieved with the semi-private function PR_FileDesc2NativeHandle function, declared in "private/pprio.h". This function is supported but must only be used when there is no alternative. It heavily depends on the properties of the current NSPR implementation. > Has anyone actually use this fd in a select or poll call (non NSPR calls)? Yes. You should also consider using the PR_CreateSocketPollFd function, also declared in "private/pprio.h". PR_CreateSocketPollFd is a better method than PR_FileDesc2NativeHandle because it does not depend on the current implementation of NSPR. PR_CreateSocketPollFd gives your native fd's just enough NSPR file descriptor wrapping so that they can be operated on by PR_Poll. It allows you to poll on a combination of native fd's and NSPR file descriptors. Wan-Teh
