Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Mar 2001 00:52:43 +0300
From:      Valentin Nechayev <netch@iv.nn.kiev.ua>
To:        Brian Matthews <blm@actzero.com>
Cc:        "'freebsd-stable@freebsd.org'" <freebsd-stable@FreeBSD.ORG>
Subject:   Re: Threads vs. blocking sockets
Message-ID:  <20010330005243.A298@iv.nn.kiev.ua>
In-Reply-To: <F0D64494733BD411BB9A00D0B74A0264021C9B@cpe-24-221-167-196.ca.sprintbbd.net>; from blm@actzero.com on Thu, Mar 29, 2001 at 09:27:20AM -0800
References:  <F0D64494733BD411BB9A00D0B74A0264021C9B@cpe-24-221-167-196.ca.sprintbbd.net>

next in thread | previous in thread | raw e-mail | index | archive | help
 Thu, Mar 29, 2001 at 09:27:20, blm (Brian Matthews) wrote about "Threads vs. blocking sockets": 

> I was encountering some problems using sockets on FreeBSD. After some
> exploration I've found that threading doesn't seem (at least in my opinion)
> to handle blocking sockets correctly. Specifically, calls to send (and
> presumably recv, although so far I've only doing recvs on nonblocking
> sockets) on a blocking socket may return having only transferred part of the
> data.

It is not correct even in case of single-threaded program. Consider,
for example, a case when waiting on blocking call is interrupted
with signal. If send() already transferred some data, it will return
number of bytes sent. If none data transferred, it will return -1 and
EINTR in errno. If you rely on sending all data in send() without
checking, your code is buggy.

> As the standard FreeBSD threads are user space, they obviously can't let the
> socket call really block, so behind the scenes all sockets are created as
> nonblocking. However, I would then expect the threaded versions of the data
> transfer calls (send*, etc.) to loop over the actual system calls. They
> actually do so to catch EWOULDBLOCK/EAGAIN (see
> /usr/src/lib/libc_r/uthread/uthreads_sendto.c for example), but don't to
> make sure all the requested data is transferred. This seems to me like a
> bug.
> 
> Thoughts, comments?

Amount of data sent is implementation-, environment- and randomness-dependent.
Your current code works in 99.9% cases, but it is buggy. Fix it.


/netch

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010330005243.A298>