Re: tselect

[Mikael Djurfeldt <mdj@nada.kth.se>]

[Sorry for not responding earlier, I'm been busy with other work.]

Maciej Stachowiak <mstachow@mit.edu> writes:

[...]

> As for this:
> > (add-select-callback <callback> <reads> <writes> <excepts> [<secs> <usecs>])
> >
> >    Add <callback> for this thread to the global set of activation
> >    subscribers.
> >
> >    For a callback, activation means that the *current* thread evaluates
> >    the callback in the dynamic context of the thread with which the
> >    callback is associated.
> 
> 
> The sole virtue I see for this over having multiple threads that use a
> new magical select is that it should (sort of) work without
> threads.

What I'm describing above is really the implementation internals.  As
I wrote in my third letter, the actual interface *can* be made to
appear completely separate from `select' (by preventing
scm_internal_select from activating call-backs except when the
interpreter is inside `event-loop').

What we have then is 1. non-blocking I/O, *and* 2. a central
event-broker, apparently completely separate, but in fact implemented
through the same mechanism, which is both nice and efficient.

The alternative is to allow event-broking also when blocking for I/O
(which would make GUI/repl support in a non-threaded system easy to
implement) but I admit that the semantics of such a system is
questionable.

> Also, it appears ill-defined what would happen if such a callback
> calls a captured continuation

This is a problem---I had missed this.  The continuations may break
this idea.

> or throws an exception that it doesn't catch

This is a lesser problem.  An error wouldn't be thrown past the
mechanism invoking the call-back.  It would instead be registered at
the associated repl.  (BTW, sooner or later we want to have a similar
mechanism for threads anyway.)

> - would the continuation do an implicit context switch?

If the continuation was created by a different thread than the one
associated with the call-back there is no problem: the correct
response in that case is to throw an error.  The problem occurs when
the continuation belongs to the "right" thread and the call-back is
executed by a different...

> In a later message, Mikael Djurfeldt wrote:
> > (define (event-loop)
> >   (select () () ()))
> 
> Unless your plans for select want to change the interface, this
> appears to be a call that blocks the current thread forever, barring
> activation of callbacks.

Yes.  It blocks the thread, which is exactly what (tk-main-loop) and
(gtk-main) also does...

> Presumably, the repl and the X event handler would be appropriate
> callbacks. Wouldn't it make more sense to just have at least one of
> those two run as the current thread, and have the other invoked as a
> callback when the other blocks in scm_internal_select?

Maybe.  Let's assume that we want to be able to install call-backs to
be run by a global event-broker when the thread is blocking for
input.  Have you a suggestion for a nice interface to such a
functionality?

[...]

> These should be more or less functionally the same, modulo locking
> issues. So really, add-select-callback just seems to be a hack to
> avoid using threads, and doesn't seem to provide too much useful
> functionality otherwise. But then, I did not see the suggested event
> broker stuff that led to this proposal.

Well, I suppose we're looking for a way to get the repl *and* a GUI to
work nicely and smoothly also on a system which qt doesn't support.

STk isn't threaded and it works OK anyway, but it does this by a
hard-wired coupling between the getc function and the Tk
event-broker.  We're looking for a way to get this coupling more
flexible---to allow applications to install this kind of couplings in
a generic way, *and* to get such code work both on systems with and
without threads.

Maybe this isn't possible.

Anyway, as Marius said in one of his responses, it is probably good
simply to implement the non-blocking functionality in
scm_internal_select for now.  As you say yourself, at least that seems
to be a reasonable thing to do.

But, folks, please continue to think about how a nice interface for
call-backs which works also on single-threaded systems could look
like!

/mdj