Question about Socket fd access in multiple tasks

[Eric Norum]

The patch looks like a good idea, but even without it I think that it's safe to have the other task perform a socket shutdown which will then cause the read in the first task to return an error, right?  The first task would then take care of closing the socket itself.

On Feb 18, 2010, at 4:04 PM, Chris Johns wrote:

> On 2/19/2010 1:52 AM, Peer Stritzinger wrote:
>> Hi,
>> 
>> consider the following scenario:
>> 
>> Task1:
>> 
>> socket -> bind -> listen -> accept -> filedesc
>> 
>> r/w on filedesc
>> 
>> then
>> 
>> blocking on read from filedesc ....
>> 
>> 
>> Later in Task2:
>> 
>> close(filedesc)
>> 
>> My question is: will the read cleanly unblock Task1 and the socket close?
>> 
> 
> No. I reported this issue back in 2005:
> 
> https://www.rtems.org/bugzilla/show_bug.cgi?id=785
> 
>> I could do experiments, but then I'll still not know if this will work
>> in all RTEMS versions and if it is intended API behaviour.
>> 
> 
> The issue is how portable you want to be. I played with a few OSs when looking into this. I found some BSDs returned from the read call with an error and some like a glibc Linux did not. The read call stayed there and given the socket did close the thread was lost. Cancelling the thread is not a good idea either. I decided for RTEMS it was best to return from the read call with an error because it made code like this simpler and smaller. For Linux and all BSDs I used the poll call and made the reads non-blocking. This worked.
> 
> It would be nice if you could dig this patch out and see how it goes in 4.10 (CVS).
> 
> Chris
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users

-- 
Eric Norum
wenorum at lbl.gov