Date: Fri, 8 Mar 2002 12:38:38 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Nate Williams <nate@yogotech.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, arch@FreeBSD.ORG Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <Pine.BSF.4.21.0203081237020.49598-100000@InterJet.elischer.org> In-Reply-To: <3C890859.4FB4F9D@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 8 Mar 2002, Terry Lambert wrote: > Nate Williams wrote: > > > You'd be surprised then because once the send() is done, the network IO > > > will happen independently of the process. > > > > I'm more thinking of send. Once the send() system call has queued the > > data for sending, it's been 'sent' (ie; the stack has it, and will > > 'DTRT' with it). > > The amount it queues onto the sockbuf is limited to the > available space. Thus a send of a very large amount of > data means that only part of it gets queued for sending. > > This is not a restartable situation, unless restart can > pick up where it left off, since the sending of a partial > load of data can modify peer state, as well, and that > state is not under the control of the user process on > your end. > > So just returning an EINTR for a send (or sendfile, etc.) > means that the peer state is unknown. STOP doesn not force an abandonment of the syscall that is SLEEPING (even I was confused about this at one stage) so RESTART stuff is not needed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0203081237020.49598-100000>