From owner-freebsd-smp Tue Oct 24 5:24:46 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id EBDB537B479 for ; Tue, 24 Oct 2000 05:24:44 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA04480; Tue, 24 Oct 2000 08:24:24 -0400 (EDT) Date: Tue, 24 Oct 2000 08:24:19 -0400 (EDT) From: Daniel Eischen To: Terry Lambert Cc: Jason Evans , Seth Leigh , smp@FreeBSD.ORG Subject: Re: SA project (was Re: SMP project status) In-Reply-To: <200010240715.AAA10142@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 24 Oct 2000, Terry Lambert wrote: > Perhaps the biggest pain is the default signal behaviour, which > no longer results in system call restart. This means that the > signal code must self-mask anything that it wants to pretend is > a system call, for every wrapping library routine. POSIX really > screwed us over on that account, kind of like what they did to > locks when you close one of several file handles to the same file. Hmm. If the method used by the kernel to notify the threads library that a thread has blocked in the kernel can also tell the threads library that it is/isn't blocked in a restartable system call, then the threads library can DTRT WRT interrupting the thread. Basically, all it would need is the system call number. It could probably get it from the context of the interrupted thread (which is passed out to the threads library under SA). There are only a few system calls that require restarting (assuming SA_RESTART is set), so I'm not quite sure what you mean by self-masking library routines. Perhaps library routines that use read(), for instance, in their implementation? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message