Synchronous/Asynchronous, one more try. [djg33]

[David Garfield]

"> " is Gary D. Duzan
"> =>" is David Garfield (me)

> =>I fully agree that either the standard library (or whatever we call
> =>it) or the kernel should include a synchronous communication layer,
> =>but still assert that the kernel must include an asynchronous
> =>communication layer at at least as low a level.  I agree that
> =>programmers should be encouraged to use the synchronous forms unless
> =>the applications calls for something else.
> =>
>    Ok, so we do both, with synchronous being primary, with asynchronous
> being equal or secondary, depending on architecture and implementation.
> Good enough?

Not Good enough.  If threads are light enough, sending a message to an
object can constitute starting a new thread.  Waiting for the message
to be finished constitutes waiting for the thread to end.

My argument is that asynchronous is the primary and synchronous is
equal or secondary, depending on architecture and implementation.

> =>Peter, my challenge stands.
> =>}} All right, try this:  under Unix, write a program that reads data from
> =>}} two data sources and does different things with the data, such that:
> =>}}         1) only one process is used
> =>}}         2) select() is not used
> =>}}         3) either data source can produce data that will be processed
> =>}}            imeadiately (sp?)
> =>}}         4) the program does not eat CPU time
> =>}}
>
>    I think my point would be that the question is flawed. :-)  You
> assume that #1 is bad, while I would say that multiple processes
> might be a reasonable way of dealing with multiple streams. If the
> processes (threads) are light enough, this shouldn't be a problem.

Multiple processes are the classical Unix way of solving this problem.
My point is that, with asynchronous I/O, it isn't needed.  And if you
needed to somehow interrelate the data from the multiple streams,
multiple processes isn't a good idea because you need to feed it all
to one process anyway.  As for the possibility of having the same
memory space for both processes, this is a possibility, but it means
you must right a fully multi-tasking application.  While many things
need to be capable of multi-tasking (like all our object management
code), we shouldn't make applications do it when it isn't needed.

Incidentally, #2 is because select() is a primative step towards
asynchronous I/O.  #4 is because the other way to solve this is to do
alternate non-blocking reads (reads that return immeadiately but
report that they did nothing), and this solutions is not compatible
with a multitasking environment.

--David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com