Question about Socket fd access in multiple tasks

[Chris Johns]

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