lkml.org 
[lkml]   [2006]   [Apr]   [13]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 13 Apr 2006 16:19:16 -0700 (PDT)
FromLinus Torvalds <>
SubjectRe: PROBLEM: pthread-safety bug in write(2) on Linux 2.6.x

On Fri, 14 Apr 2006, Alan Cox wrote:
> 
> Interesting. That pretty much conflicts with what write(2) itself is
> defined as in the same specification

They may mean that writes get "as much atomicity" between threads as 
specified in other places (which is not a whole lot). In which case we're 
certainly totally according to spec (since Linux has exactly the same 
guarantees for threads as for anything else - since we just don't even 
_care_ if it's a thread or not).

It may be that the extra POSIX wording comes from user-space thread 
libraries that did "magic things" with select loops etc for IO using 
non-blocking file descriptors (which, together with some latency 
guarantees, could turn a single write into a series of smaller blocked 
writes).

That would explain the POSIX wording - that they are supposed to be "as 
thread safe" as a native write, even when they are wrapped inside a magic 
threaded IO library. Maybe the "in the effects specified in IEEE Std 
1003.1-2001" part is exactly about the fact that write is _not_ actually 
specified to be totally atomic by the _normal_ POSIX stuff, but that they 
wanted to make it clear that it's supposed to be "as atomic" as it's 
supposed to be.

Hmm? Trying to be a language lawyer over a spec is always painful. I'd 
suspect that the people who wrote that part didn't even really think about 
it a lot, they just meant that they were "thread safe" in the sense that 
you can call them concurrently without the system blowing up.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-04-14 01:22    [from the cache]
©2003-2008