Date: Fri, 8 Mar 2002 12:36:44 -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.0203081210200.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). Ok here is a summary of behavioural changes I think we'd see. *** From the program point of view: Pretty much no change. *** From a debugger's point of view: Pretty much no change.. SIGCHLD arrives when you may examine the process's mamory without bumping into a running thread changing things. *** From a completely unrelated process's point of view: if you are receiving data from the process in question, there may be the following changes: 1/ if you ^Z the sender, when it is doing a write that is large enough to overflow the send buffer, so that it needs to do it in several bites, then at the moment, the data flow may be paused between these bites, say after 16k out of 33KB written. In the new case the entire 33K would be written, after which the thread would block. If you can type ^Z that fast that this makes a difference to you on a 10Mb ethernet, I'd be amazed. Someone looking on a slow link might notice, but I'd be surprised if it mattered to anyone considering that the default buffer size would probably effect this same stop point as well. 2/ similar with sendfile. The entire file would continue to be sent, however the process wouldn't be able to tell the difference. it would be stopped. I think that sendfile could be special case'd if we desperatly needed that behaviour (the ability to ^Z the server would stop the stream) but I doubt anyone would really care. 3/ If you are talking TO a process that is ^Z'd, it might read a bit more data from the receive buffers before blocking, which might mean that the sender can send that much data extra before blocking. I doubt that this would be noticed by anyone in this galaxy. A definition of STOP that includes "will stop immediatly if in user space, or AFTER the current system call completes if in the kernel" would pretty much describe it. 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.0203081210200.49598-100000>