Re: [9fans] X on Plan 9

[David Rubin <dlrubin@hotmail.com>]

forsyth@vitanuova.com wrote:
>
> >>What do you mean by "non event-driven?"
>
> i supposed he meant `not using callbacks' (ie, quasi-interrupts on each
> event) to drive the computation, but instead using communicating
> sequential processes to express the interaction of computer and
> events in the environment, allowing the use
> of a more reasonable programming style (in the sense that you can
> reason about them and the effects on data structures and values).
> i've found callback-based programs typically shrink when converted, but i
> suppose that's not necessarily true.

So basically the claim is that reading a ctl or data channel for "events" or
commands is better than reading events from an event queue because in the "non
event-driven" method the OS does is not as involved since it does not have to
generate and post events?

I am confused on this issue. Plan9 generally makes claims along the lines of
"easier to reason about..." and "[cleaner/simpler] programming style" to support
its approach to distributed communication. Can you give a little more detail
about why this is so?

For example, I am programming in a VxWorks environment now, and we have
communicating tasks which post events to each other. The events might signal
various timeouts or "enqueued data" events. In the case of an "enqueued data"
event, the receiving task then reads a message from a queue. This is basically
my impression of how an event-driven gui would work as well. How would a
non-event driven model of inter-task communication make such programs simpler to
write and easier to reason about?

Please correct me if I am mixing terms...Thanks.

	david

--
If 91 were prime, it would be a counterexample to your conjecture.
    -- Bruce Wheeler