C level threads...

C level threads...

[Marius Vollmer]

Ok, I have documented and implemented the C level thread API (mostly
unchanged from what we had before I deprecated it), and reorganized
the thread implementation to revolve around this API.  The difference
between null-threads and coop-pthreads (implementation-wise, not
behavior-wise) is now very small, which should be a good thing.

I haven't yet ported coop threads over to the new arrangement, tho,
since I didn't had the time and I wanted to commit what I had anyway.
I will come back to this and reinstall coop support, hopefully soon.

Anyway, the default is now coop-pthreads and I think we should keep it
that way.  Threads should not be some thing that you have to configure
into your Guile and where you are lucky that you can get them, they
should be something that is always there (unless configured away).

The C level API is not pluggable yet, and I have to admit that I
didn't plan for that, but the thing is still 'hot' and ductile so if
someone wants to work on pluggable threads...

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: C level threads...

[Mikael Djurfeldt]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Ok, I have documented and implemented the C level thread API (mostly
> unchanged from what we had before I deprecated it),

Great!

But, there are several incompatible changes to the API.  I'm concerned
with the removal of the second argument in the creation functions.
I'd like you to add back this second arg because:

1. The second arg in scm_mutex_init and scm_cond_init contain flags
   some of which we might want to support in the future.  It would
   feel awkward to have to incomapibly add the second arg again...

2. In my view, we should actively support the second arg in
   scm_key_create already now.  That argument can be downright
   necessary for some applications.  The same probably holds for
   scm_thread_join.  Why not simply conform to the pthreads API in
   these two cases?

3. I don't find any compelling reason not to stay backward compatible.

> The C level API is not pluggable yet, and I have to admit that I
> didn't plan for that

No big problem, I think, since we can always

  #define scm_mutex_lock(mx) scm_thread.mutex_lock (mx)

Best regards,
Mikael


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: C level threads...

[Mikael Djurfeldt]

A further point:

I think you originally aimed for the Guile "disguise" of the pthread
API to be so close to the pthread API that it introduces zero
overhead.

But if you:

#define scm_mutex_lock(mx)    pthread_mutex_lock (mx)

guile-gtk-1.2 can't plug in scm_mutex_lock into glib's thread
interface.

Why can't we just keep the API as it has been the last few years?

According to the original API, the entries should be functions or
function pointers.  Then the above should be:

#define scm_mutex_init    pthread_mutex_init
#define scm_mutex_destroy pthread_mutex_destroy
#define scm_mutex_lock    pthread_mutex_lock

etc.

Can't we simply adhere to the old API without incompatible changes?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: C level threads...

[Marius Vollmer]

Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:

> 3. I don't find any compelling reason not to stay backward compatible.

Ok, I see.  I will answer more fully later, but I think these are
valid points and I'll make the thread API backwards compatible again.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: C level threads...

[Mikael Djurfeldt]

OK, a final rant about the new thread API:

I think the names scm_key_setspecific and scm_key_getspecific are
misleading.  The sound like they are operations which operate on keys,
but they are not!  scm_key_create should be named so because it
creates a key.  However, current scm_key_getspecific gets thread
specific *data*.  It gets something *using* a key, but it's the thread
data which is the central thing.  This is why we have the names
pthread_key_create but pthread_getspecific.

Even if I didn't find the pthread library names more intuitive, I'd
still think it's a better idea to conform to them.  Creating slightly
different names only creates confusion.

Mikael


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel