Question about Socket fd access in multiple tasks
chrisj at rtems.org
Fri Feb 19 00:04:17 UTC 2010
On 2/19/2010 1:52 AM, Peer Stritzinger wrote:
> consider the following scenario:
> socket -> bind -> listen -> accept -> filedesc
> r/w on filedesc
> blocking on read from filedesc ....
> Later in Task2:
> 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
More information about the users