Re: [Chicken-users] Re: An alternative thread system?

[Elf]

On Mon, 11 Aug 2008, Shawn Rutledge wrote:

> However what about the case where there is a UI event loop and the
> same program also has to poll one or more event sources, such as dbus,
> or a socket or a pipe, for output from one of those helper processes
> that you redesigned to be a process rather than a thread?  In C your
> main choices are to use select() to wait for an event from any of
> those sources (only as long as your program has nothing else to do
> while it's waiting, and as long as you can gather all the file
> descriptors into one list to be able to use select), or use
> non-blocking I/O and poll each source manually, or use threads to
> pretend that you can poll everything in parallel.

this is one of the good uses of threading, yes :) 
it is possible to design an equivalent structure using neither threads nor 
polling (Except when theres nothing else to do), its just a hideous thing.
(also, select Does Not Do What You Think It Does in Windows)

>

> In the dbus egg I use a polling thread (a Chicken thread not a native
> one).  This hides the complexity nicely: the user of the egg does not
> need to care about polling, it appears instead that the appropriate
> callback function can be called spontaneously when a DBus event
> occurs.  If I wish to preserve that interface, do I really have any

no, of course not.  this is one of the few areas where threads are a clear
win.  theres a reason... the worker threads dont have effectively limitless
extent.  replace 'thread' with 'procedure' and youll get the same results :)
this type of threading, for x gooey stuff... thats one of the few really
clear wins.  this may have something to do with threading and parallelism 
getting lots of attention partially due to this idea of 'event loops' for
'graphical interfaces' ... in 1983 or so :)


> Maybe Chicken could have a higher level abstraction for callbacks.  It
> would then have the choice of using either select() or threads under
> the covers.

theres a much higher-level waiting semantics for io that is nearly complete
(because select doesnt do what you think it does on all systems.  particularly
windows.)  explain more about what you want from callback abstraction?


> A long time ago (when working at my first software job, which happened
> to be on OS/2)

You'd admit to working on OS/2?  Brave man.

> it struck me

I would have too. :)

>  that it's too bad events which originate
> from hardware often have to be polled in software.  E.g. a UART
> generates an interrupt when a character is received; the OS handles it
> and puts the character in a buffer, and the application must poll the
> buffer to see when there is data available.  Maybe the OS could tell
> the interested application each time a character is received (and
> still do the buffering, in case the app doesn't want to handle each
> character one-at-a-time).  Of course it works well enough, it's just a
> philosophical thing.  (And maybe in fact when using select(), maybe
> breaking out of this blocking call is in fact triggered directly by
> the interrupt?)  So I guess I'm thinking along the same lines about
> callbacks in general: "tell me when X happens" should not have to mean
> "waste a bunch of cycles polling until X happens and then call me."
> But as long as polling threads are the only practical way to do
> callbacks, there is no chance to even try to do an optimization like
> that.a

first, its not a practical optimisation.
for a keyboard, or a small-payload character oriented device, sure.
how about a network card?  single byte input isnt useful unless you only
have one potential reader and one potential writer.  it also would make it
very hard to handle things like packet defrag.
second, are you familar with the various distributed programming efforts?
termite may be a good place to start.  theres ivan raikov's excellent mpi
eggs.  theres all sorts of parallelism and synchronicity eggs in the repo.


theres also smart scheduling of threads, which im trying to work out.


-elf

>