Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.unix.questions Subject: Re: async I/O (was: Is there a select()-like call for message queues?) Message-ID: <8U41SMDxds13@ficc.uu.net> Date: 17 Jan 90 23:05:30 GMT References: <1826@xyzzy.UUCP> <11925@smoke.BRL.MIL> <11950@smoke.BRL.MIL> <11956@smoke.BRL.MIL> <11968@smoke.BRL.MIL> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 54 In article <11968@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > In article peter@ficc.uu.net (Peter da Silva) writes: > >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". You sound like me (see my occasional diatribes against X in comp.windoows.*). However with a conventional programming language it's the only way to do it, unless you go all the way to UNIX processes... and that's too slow. > >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. Yes, that's an understatement. Replacing all System V's shm_* calls with something like map_fd() (from Mach) would help. But context switch overhead is still too high for realtime work. > 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. Multithreaded applications are difficult in many languuages, even when the operating system is up to snuff. This is a language problem... > 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. First, you keep telling me I'm *forcing* processes to deal with awrite(). I'm not. I'm saying it should be an option. Secondly, you can implement threads on top of asynchronous I/O calls. I've done this for Forth under RSX-11. You have to have an explicit context switch routine, but that simplifies the programming immensely anyway. You just include checks for completed I/O in the swtch() routine. I laid out the outline for such a routine in comp.lang.c some months ago, and at least one person has turned it into a real concurrent "library" for C. *If* UNIX supported await() and friends, then you could efficiently implement a concurrent programming language. In fact, you could use C plus a set of small routines to switch to a new context. But it doesn't. Pity. Your serve. -- _--_|\ Peter da Silva. +1 713 274 5180. . / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'