[Resend from 14th May --- the original didn't appear on the nfs-discuss forum, I don't know if David received it. This time I'm trying without signing my email]
Hi David, > According to the man pages the MT-Level of xdr_opaque() is "Safe" and > not "MT-Safe". If I have multiple threads that each create their own > XDR stream using xdrrec_create() and the buffer for each stream is > tied to a separate socket is it safe to be calling xdr_opaque() at > the same time from each of the threads (in XDR_ENCODE) mode? That would be my understanding. As I'm sure you've found, the MT-Safe attributes are defined in the attributes(5) man page. That makes a distinction between "Safe" and "MT-Safe" though I had to read it a few times :-) As FrankB suggested in his email to your other recent thread, the AnswerBook is surprisingly useful: ONC+ Developer's Guide <http://docs.sun.com/app/docs/doc/805-7224> Multithreaded Programming Guide <http://docs.sun.com/app/docs/doc/816-5137> IIUC xdr_opaque() is safe to call in MT programs but the programmer must provided appropriate synchronisation, eg to avoid two threads writing to the same output stream simultaneously. You could either provide locking in the readit()/writeit() functions you pass to xdrrec_create() or in the caller. > I'm seeing problems where the xdr_opaque() returns with FALSE, but of > course there is no indication of what the problem is. I've looked at > some of the source code and it looks like the main place there could > be a failure is with the flush_out() call that is called from > XDR_PUTBYTES(). > > The sockets that are being used are non-blocking, that I'm > controlling using a select() call. I'd start by tracing the readit()/writeit() calls. > I usually see the xdr_opaque() call return false, but since I'm also > using xdr_int, xdr_string, and others the same question concerning > thread safety is relevant to those calls. As I think they all end up calling the provided readit()/writeit() calls that's why I'd be looking at the readit()/writeit() calls. -- Peter