Date: Fri, 5 Mar 1999 23:03:48 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: tlambert@primenet.com, dyson@iquest.net, dick@tar.com, jplevyak@inktomi.com, hackers@FreeBSD.ORG Subject: Re: lockf and kernel threads Message-ID: <199903052303.QAA05576@usr06.primenet.com> In-Reply-To: <199903051829.KAA82072@rah.star-gate.com> from "Amancio Hasty" at Mar 5, 99 10:29:54 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I think that completion functions are less useful than select type > > functions. For VMS, this would be SYS$WAITEFLOR, which waits for > > an event flag to be set by an AST callback into event-flag-setting > > code. > > > > You have to use a "wait for completion" interface of some kind if > > you intend to implement threads, since, the wait is the top of the > > call conversion scheduler pyramid. > > You have a good point however wouldn't prioritized ASTs be able to accomplish > same thing? Actually, yes. Practically, though, even though select(2) can be used to implement I/O stream multiplexing, when use in combination with a finite state automaton, most programmers have a hard time getting their heads around non-procedural problem decomposition. Just like threads allow programmers to program linearly, making them popular even when they aren't strictly necessary (e.g. all non-SMP OS's, and many SMP OS's with poor architectures), I think that most programmers would find the non-linearity of AST priority juggling difficult to wrap their heads around. It's not that it's not possible, it's just that there are so few people who could program effectively in that model. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903052303.QAA05576>