Date: Thu, 29 Mar 2001 11:46:55 -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.33567.94042.80830@nomad.yogotech.com> In-Reply-To: <F0D64494733BD411BB9A00D0B74A0264021C9C@cpe-24-221-167-196.ca.sprintbbd.net> References: <F0D64494733BD411BB9A00D0B74A0264021C9C@cpe-24-221-167-196.ca.sprintbbd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> | > However, I would then expect the threaded versions of the data > | > transfer calls (send*, etc.) to loop over the actual system calls. > | Why? Do other OS's not require you to check your return values, to make > | sure that the call sent everything you expected it to? > > In my experience (on 4 or 5 Unix variants), with a blocking socket either > everything is sent or an error (or EOF on recv*) is returned. In fact > FreeBSD also does this, unless you link with libc_r instead of libc. Right, but in threaded systems, there are no 'blocking' sockets. You have to think differently when doing threaded applications. 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.33567.94042.80830>