In-Reply-To: <MDEHLPKNGKAHNMBLJOLKOEHMGBAC.davids@webmaster.com>
References: <MDEHLPKNGKAHNMBLJOLKOEHMGBAC.davids@webmaster.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5E4153F3-80E6-4425-A5C8-47E29A549030@nocrew.org>
Cc: <linux-kernel@vger.kernel.org>
Content-Transfer-Encoding: 7bit
From: Fredrik Noring <noring@nocrew.org>
Subject: Re: Improving read/write/close system call reliability when used with pthreads
Date: Mon, 13 Aug 2007 08:50:39 +0200
To: davids@webmaster.com
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1198
Lines: 38

David,

True. Even though there is a point in making the kernel detect and  
behave consistently in this case applications (often) end up with  
their own mess they cannot easily handle. A few more use cases would  
now work OK but probably not enough to make the improvement worthwhile.

Thanks,
Fredrik

13 aug 2007 kl. 05.14 skrev David Schwartz:
> Since there's no atomic "unlock and read" function, any code that  
> could ever
> close a socket in one thread while another thread is blocked on  
> read might
> call close just before another thread blocks in read. Nothing stops  
> another
> thread from opening something, getting the same file descriptor,  
> and then
> allowing the thread to call "read" on the wrong file descriptor  
> entirely.
>
> Since this can never be made sane in general, I see little point in  
> making
> one variation of what can go wrong a bit saner. It is still  
> irresponsible to
> code like this.
>
> DS
>
>
>

-
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/