On Mon, May 15, 2006 at 06:50:36PM -0700, Mark A Smith wrote: > > I cannot think of another possible definition for thread-safe in the > context of these functions. Certainly they should not cause a "crash" when > called from multiple threads, but that's a requirement independent of > thread-safety. ... > I think the question really boils down to: "What does thread-safe mean with > respect to send()?" It might be more easily answered by asking, "How would > a non-thread-safe send() behave?" I think it would behave the way we're > seeing it behave.
A non-thread-safe send() could use a global buffer to hold copied data or results. When called from multiple threads it could lose data or mix data from send()s to different sockets. Or it could return a result in one thread that reflects the result of an overlapping send() in another thread. Or it could sometimes core dump. The behavior of a non-thread-safe function called from multiple threads is undefined. There is really no requirement "independent of thread-safety" on the behavior of a function called from multiple unsyncronized threads. As Rick noted, this is not really a threading test but a multiprocess test. A requirement to be thread-safe shouldn't imply anything about the behavior of functions in single-threaded processes. The posix standard has a limit of PIPE_BUF bytes for atomic writes to a pipe. That might extend to expecting sends of under PIPE_BUF bytes to be atomic on a socket. But I don't actually find any guarantee of atomic writes for sockets, even for sizes below PIPE_BUF. -- Mike Stroyan, [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
