Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.unix.questions Subject: Re: async I/O (was: Is there a select()-like call for message queues?) Message-ID: <11968@smoke.BRL.MIL> Date: 17 Jan 90 14:25:57 GMT References: <1826@xyzzy.UUCP> <11925@smoke.BRL.MIL> <11950@smoke.BRL.MIL> <11956@smoke.BRL.MIL> Reply-To: gwyn@brl.arpa (Doug Gwyn) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 38 In article peter@ficc.uu.net (Peter da Silva) writes: >First, a nitpick. By 1974 UNIX was basically in its current form, and its >design goals must have been established earlier than that. But that's just >a nitpick. Yes, Ken Thompson was thinking about these issues too, as far back as 1969 for sure and probably well before that. >Secondly, I'm not suggesting that applications be forced to explicitly >deal with asynchronism. I just believe that since the real world is >asynchronous you should be able to deal with it. I would rather have it under control than have to deal with it ad lib. >Also, the event-loop construct has considerable success in the real world >for dealing with asynchronous events. Ha! Practically everybody I know who has had to program event loops thinks "there has to be a better way". The fundamental problem with event loops is that it forces the application to maintain state information merely to properly schedule the application's actions. This (tedious and error-prone) bookkeeping is unnecessary when using better methods for handling asynchronism. >Unfortunately, UNIX doesn't support a sufficiently fine-grained process >structure to allow this [CSP] to be generally used. Actually, it does pretty well, but in most implementations its IPC needs improvement. Also, there is no reasonable programming language for exploiting this approach other than the shell language, which is too limited and difficult to use in this area. >I'm sure it can. But not under UNIX as it exists, and not under any >extension of UNIX that I've seen that still remains close to the source. The issue was the best way to extend UNIX to give applications better control over asynchronism. I made suggestions for better methods than forcing processes to deal with awrite() etc.