From owner-freebsd-arch  Fri Mar  8 12:40:36 2002
Delivered-To: freebsd-arch@freebsd.org
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38])
	by hub.freebsd.org (Postfix) with ESMTP id 2637E37B420
	for <arch@FreeBSD.ORG>; Fri,  8 Mar 2002 12:40:10 -0800 (PST)
Received: from InterJet.elischer.org ([12.232.206.8])
          by rwcrmhc51.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20020308204009.KOOU2626.rwcrmhc51.attbi.com@InterJet.elischer.org>;
          Fri, 8 Mar 2002 20:40:09 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA49904;
	Fri, 8 Mar 2002 12:38:39 -0800 (PST)
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)
In-Reply-To: <3C890859.4FB4F9D@mindspring.com>
Message-ID: <Pine.BSF.4.21.0203081237020.49598-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG



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