Re: [Chicken-users] simple threading

[Joerg F. Wittenberger]

Am Samstag, den 17.06.2006, 23:35 +0200 schrieb felix winkelmann:
On 6/17/06, Joerg F. Wittenberger <address@hidden>
wrote:
> > Hi Felix,
> >
> > I've been contemplating...could chicken include some basic support
> > for
> > native thread communication?
> >
> > rscheme has these C functions
> >
> > void rscheme_intr_call0( obj thunk );
> > void rscheme_intr_call1( obj proc, obj arg );
> > void rscheme_intr_call2( obj proc, obj arg1, obj arg2 );
> >
> > which basically enqueue a "virtual" signal, which is then
> > processed
> > similar to system level signals.
> >
> > BTW: I feel that it might be safer/easier and just enough to
> > provide
> > only the first (thunk) version.
> >
> 
> Not a bad idea... What should this do in particular?
> 
Short answer: schedule thunk/proc for execution at the Scheme side.
Whatever that means for the Scheme runtime system.

Long answer: ... (straight&unchecked from my weak brain; we had a good
party tonight; I just got up; sorry if the rest doesn't make too much
sense :-/  )

I recall rscheme maintaining some event system (queue? no memories).
A select loop controls time slices and async i/o.  C signals are
queued (by default) and this select loop will eventually call
registered handlers on the queued signal.  Now rscheme_intr_call0 puts
a virtual signal into the queue and the handler will just call (thunk)
in the appropriate context, i.e. from the thread running the whole
Scheme side, not the second native thread.

The "most users will..."-lie: most users will associate the *_call0
with some native<->Scheme communication channel and protect with
semaphore.  So the following protocol applies (assuming pthread being
the native thread system):

Native side:

pthread_lock_sema(scheme_sema);
my_channel->data=result;
_intr_call0(my_channel->thunk);


Scheme (application level) side:

(let ((result (my-channel-data)))
  (unlock-scheme-sema)
  result)


For the chicken system, I could imagine that chicken_intr_call0 would
just create a thread to execute thunk and register that with the
scheduler.  I'm not sure why there should be some queue system.

best regards

/Joerg