This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Threads in Guile
- To: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Subject: Re: Threads in Guile
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 31 May 2000 23:41:41 +0200
- Cc: NIIBE Yutaka <gniibe at chroot dot org>, Guile Mailing List <guile at sourceware dot cygnus dot com>
- Cc: djurfeldt at nada dot kth dot se
- References: <Pine.LNX.4.21.0005311146350.20418-100000@marvin.ida.ing.tu-bs.de>
Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:
> I have already started to figure out how to extract the coop thread
> support from guile.
Super! 8-)
> I am not sure about the preferred overall design,
> though, so I will describe you what I have done so far (nothing of this is
> in cvs yet):
We should put it on a cvs branch. You could do that now. That would
make it easier to cooperate.
> 1) threads.[ch] has no link to the coop/quick threads code any more.
Good.
> 2) the code from coop-defs.h, coop-threads.[ch] and coop.c is merged into
> the files guile-qthreads.[ch]. This is the glue code between the
> generic threads interface and the qthreads library.
You should probably replace the name "qthreads" with "coop". Guile is
using coop threads, which are built upon qthreads. The guile-coop
glue should probably not refer in any way to qt, btw.
Your guile-qthreads.c should be split into coop.c, having no reference
to Guile, and guile-coop.c, which is the glue code.
> Nowhere in guile there is a reference to the things in guile-qthreads
> any more with one exception: iselect.[ch] And, the stuff in there is
> heavily connected with the implementation of the coop
> threads. Unfortunately, I don't really understand what is going on
> there. I am about to dig myself through it, but I would be thankful if I
> could get information from you to make that digging easier. Maybe
> there has been some discussion about how that stuff could be implemented
> in a more generic way? I will not look into it before friday, then I will
> appreciate any enlightening mails :-)
It is true that iselect.c is really a part of coop threads. Move it
to coop.c.
We should extend the generic threads interface with a `select' entry.
libguilecoop installs coop_select (renamed from scm_internal_select).
libguilepthread installs select (the OS function).