Path: utzoo!attcan!ncrcan!scocan!seanf
From: seanf@sco.COM (Sean Fagan)
Newsgroups: comp.unix.misc
Subject: Re: UNIX semantics do permit full support for asynchronous I/O
Message-ID: <1990Sep5.142127.13771@sco.COM>
Date: 5 Sep 90 18:21:27 GMT
References: <1990Aug29.170931.10853@terminator.cc.umich.edu> <31445.26dc0466@ccavax.camb.com> <1990Aug31.142906.26633@uncecs.edu> <1990Sep04.014353.15085@gorgon.uucp>
Reply-To: seanf@sco.COM (Sean Fagan)
Distribution: usa
Organization: The Santa Cruz Operation, Inc.
Lines: 33

In article <1990Sep04.014353.15085@gorgon.uucp> dag@gorgon.uucp (Daniel A. Glasser) writes:
>As an extension to Unix, I would suggest the following:

I wouldn't (reasons below), but a small comment on your method anyway:

>  int writea(int fileno, void *buffer, size_t buflen, void (*complete_rtn)());
>  int reada(int fileno, void *buffer, size_t buflen, void (*complete_rtn)());

Change that the 'complete_rtn' to:

	void (*complete_rtn)(int)

where the parameter is the return value of the call, either the number of
bytes read/written, or the failure/return code.  Perhaps - <errno> on
failure?

Anyway:  why I wouldn't do it.  (I just got involved in this discussion with
a friend last night, btw, so the arguments are fresh in my head 8-).)

The asynchronous reads/writes can be simulated now, in SysV and (I think)
BSD fairly easily, using shared memory, fork, and signals.  If you're going
to change the kernel enough to add this, I would suggest that it would be
better to go all out and add threads to your system.  They are more generic,
which means that it's not exactly what you want to do, but it's also more
flexible, and can be extended to do other things.

Just my opinions, of course...

-- 
Sean Eric Fagan  | "let's face it, finding yourself dead is one 
seanf@sco.COM    |   of life's more difficult moments."
uunet!sco!seanf  |   -- Mark Leeper, reviewing _Ghost_
(408) 458-1422   | Any opinions expressed are my own, not my employers'.