UNIX semantics do permit full support for asynchronous I/O

Sean Fagan seanf at sco.COM
Thu Sep 6 04:21:27 AEST 1990


In article <1990Sep04.014353.15085 at gorgon.uucp> dag at 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 at 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'.



More information about the Comp.unix.misc mailing list