Date: Thu, 29 Mar 2001 12:04:04 -0700 (MST) From: Nate Williams <nate@yogotech.com> To: Brian Matthews <blm@actzero.com> Cc: "'nate@yogotech.com'" <nate@yogotech.com>, "'freebsd-stable@freebsd.org'" <freebsd-stable@FreeBSD.ORG> Subject: RE: Threads vs. blocking sockets Message-ID: <15043.34596.749224.205511@nomad.yogotech.com> In-Reply-To: <F0D64494733BD411BB9A00D0B74A0264021C9D@cpe-24-221-167-196.ca.sprintbbd.net> References: <F0D64494733BD411BB9A00D0B74A0264021C9D@cpe-24-221-167-196.ca.sprintbbd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> | Right, but in threaded systems, there are no 'blocking' sockets. You > | have to think differently when doing threaded applications. > > Well, at some level there aren't any blocking sockets anywhere. In > nonthreaded programs, the kernel "loops" for you. I'd expect the wrapper to > do the same in a threaded program, and in fact it does, sort of, catching > EWOULDBLOCK/EAGAIN and suspending the thread if the socket is blocking. > > I could (almost :-)) see saying "sockets are always nonblocking in a > threaded program", but the current implementation says "sockets can be > 'half-blocking' (i.e. we'll handle not being able to transfer anything right > now, but we won't handle a partial transfer) in a threaded program". Again, in other threading systems I've used, the caller must check to see if the call has sent all the data. FreeBSD is not special in this regard. Nate 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?15043.34596.749224.205511>