Question about Socket fd access in multiple tasks

Chris Johns chrisj at
Fri Feb 19 00:04:17 UTC 2010

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:

> 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).


More information about the users mailing list