Re: Thread interface issues (was Re: C level mutices and condition variables)

[Neil Jerram]

>>>>> "Mikael" == Mikael Djurfeldt <address@hidden> writes:

    [summary of thread issues and why he wants a C thread API :-)]

Oh dear.  Having supported Marius' proposal earlier, I now find
Mikael's arguments quite persuasive.  So I will try to help by
summarizing the point of disagreement, then revisit the earlier
conversation where Marius persuaded me of his proposal.

(FWIW, I did have a few second thoughts about removing scm_t_mutex
even before Mikael raised questions, when something that ttn said on
guile-user reminded me of past arguments ...)

So, the gist.  MDJ wants a C API (with a Scheme API on top of it) for
- back compatibility
- performance
- similarity to pthreads interface.
MVO prefers a Scheme API that is callable from C for
- ability to put SCM data inside mutexes etc. without worrying about GC
- because static declaration of scm_t_mutex needs to change anyway.

Revised notes on our earlier conversation:

>> Neil Jerram <address@hidden> writes:
>> 
>> > - Why would you want "to have SCM data in a scm_t_mutex"? - isn't the
>> > data that you are protecting access to normally a separate variable
>> > (or set of variables) from the mutex itself?
>> 
>> I was thinking about data that is needed to implement the mutex
>> itself.  It would be nice to be able to use SCM values, I'd say, just
>> because a SCM string as the mutex name is nicer than a C string.

2nd thoughts: why does a mutex need a name?  Didn't we recently remove
names from variables because they were unSchemely?

>> Concretely, I wanted to use SCM lists to implement the waiting queue
>> (to add fairness to POSIX mutices), mostly because SCM lists are
>> already there and why shouldn't I use them then?

Given the renewed discussion, could we not have both

- a low level, implementation-dependent scm_t_mutex, with no fairness
  guarantees, that is as native as possible w.r.t. the thread impl

- fair SCM mutexes built on top of scm_t_mutex.

>> > - What do you mean by not abstract enough?
>> 
>> You will declare scm_t_mutex variables and thus the size of the
>> scm_t_mutex structure can not change.  When we want to select mutex
>> implementations at run-time, that might be a (small) problem.

If we keep scm_t_mutex after all, it would be nice if existing
applications didn't have to change their code.  If it is already a
requirement to call scm_mutex_init, couldn't scm_t_mutex have a
pointer to some other structure that was dynamically allocated by
scm_mutex_init?

>>                                                                In any
>> case, I think it is better to hide mutices behind SCM values, just as
>> other data structures.

This may be the key point.  What other structures in Guile are most
like mutexes for the purposes of this comparison?  Why are mutexes not
like integers, which are represented by both int and SCM?  If mutexes
are most like other SCM types, is it the possibility of multiple
underlying thread implementations that motivates a non-SCM-based C API
for them?  Why don't we have the possibility (or problem) of multiple
XXX implementations for other kinds of XXX in Guile?

(All genuine questions.)

        Neil