From owner-freebsd-hackers Fri Jan 23 07:04:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA08623 for hackers-outgoing; Fri, 23 Jan 1998 07:04:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from word.smith.net.au (ppp11.portal.net.au [202.12.71.111]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA08611 for ; Fri, 23 Jan 1998 07:04:20 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id BAA01122; Sat, 24 Jan 1998 01:26:45 +1030 (CST) Message-Id: <199801231456.BAA01122@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: daniel_sobral@voga.com.br cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: uiomove() In-reply-to: Your message of "Fri, 23 Jan 1998 12:09:19 -0300." <83256595.0050574F.00@papagaio.voga.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 24 Jan 1998 01:26:44 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > > If you only support one stream at a time, there is no requirement > > to synchronise your input or output at all. I would do something > > like this: > > > s = splsoftclock(); > > while (sc->nwaiting > 0) { > > tsleep(&sc->nwaiting, PCATCH, "cryptwrite", 0) > > } > > splx(s); > > I have seen code like this elsewhere... tell me, won't crypt_timeout() be > blocked by splsoftclock() during the tsleep()? (The answer seems to be > "obviously, no", but I'd rather be sure than obvious. :) "Obviously, no" 8) tsleep() puts your current context to sleep, and selects a new one to run. It also preserves the calling spl and restores the spl for the new context. This lets you avoid the race condition between the test and the sleep. > Also, since you do splsoftclock(), wouldn't a PRISOFTCLOCK (if there is > such a beast) be reasonable as a parameter to tsleep()? If there is, sure. > Also, isn't "cryptwrite" too big for tsleep()... :-) :-) Dunno. Its certainly too big for ps et al. > I may end up using your hmuch trick, though. There are a few other things I left out, particularly the correct handling of returns from tsleep() when PCATCH is specified. > > splsoftty() prevents soft tty interrupts (timeouts used for tty > processing). > > splsoftclock() prevents software clock (timer) interrupts. > > So... timeout(9) is blocked by splsoftclock(), and splsofttty() may or may > not block timeout(9) (probably "may"), but do block other kinds of timeouts > I have not seen (because I have read much of tty code) which are used by > tty? splsoftty() can only be expected to block soft tty interrupts. These are the soft interrupts that move things through the tty subsystem. I'm not sure I can parse the rest of your question though. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\