About removing the low level thread API

[Marius Vollmer <marius.vollmer@uni-dortmund.de>]

Hi,

I am not completely happy about having removed the low level thread
API.  

I do think that it is not the job of Guile to provide such a thing and
I also found its presence to be confusing, when compared with the
'regular' thread API.

On the other hand, Guile itself both works on systems that do provide
a pthread API, and on systems that do not.  C code written for Guile
might want to support both cases as well (being properly thread safe
by default, but still compilable even when the pthread API is not
available).

So, since Guile has already solved the problem of adapting itself to a
non-pthread system via a very thin layer, it might just as well export
this mechanism so that C code written for Guile does not need to
provide that layer on its own.

(That layer would be very much like the pthreads API.  On a pthread
system, it would map directly to the real pthread functions, on a
pthread-less system, it would mostly be noops.)

The argument against this would be that such a thin adaptation layer,
once exported, needs to be complete enough to be useful and we need to
maintain it.  We might not want to worry about this, since, well, it
is not the job of Guile to provide an alternative to pthreads.


More conretely, we had the following functions:

  - SCM scm_lock_mutex (SCM mutex)  
  Locks a Scheme-level mutex.  Same as 'lock-mutex' in Scheme.

  - int scm_mutex_lock (scm_t_mutex *mutex)
  Locks a low-level mutex.

I want to remove scm_mutex_lock (and all other functions in the
low-level API) and maybe, just maybe, provide instead

  - int scm_p_pthread_mutex_lock (scm_p_pthread_mutex_t *mutex)
  Identical to pthread_mutex_lock on systems with pthreads and when
  Guile has been configured --with-thtreads; otherwise, does nothing
  and always returns 0.

Would you say that such alias for the pthreads API is useful?

Guile needs it internally anyway, but when we do not export it, we can
just implement what we need and can change it at will, of course.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user