coop-pthreads + gtk-threads

coop-pthreads + gtk-threads

[Mikael Djurfeldt]

Hi,

I want to update some of my applications to support guile-1.7.0.  This
includes guile-gtk-1.2.  I'd very much like gtk-threads.c to work with
guile regardless if the admin has installed it with coop-threads or
coop-pthreads.  Have you worked on this?  Do you know if anyone has
worked on getting guile-gtk-1.2 to work with 1.7.0?

I actually have a set of patches for this.  Are you or Ariel
interested?  (Or maybe you plan to go about (or have already) with
1.7.0 support in a different source tree?)

Regarding coop-pthreads:

When working on Guile's threads previously I've always tried to
maintain a clear separation between Guile scheme level primitives and
the thread package itself.  This way, it was possible to use the
thread package from C level without involving SCM objects and the
garbage collector, and it was easy to "plug in" COOP threads into
Gnome's glib.

In coop-pthreads these two "levels" have been mixed.  While
coop-threads.c is a Guile interface to the coop library in coop.c,
coop-pthreads.c performs the double role of implementing Scheme
primitives and implementing the thread package itself.

As you can guess, I discovered this when looking for
copt_mutex_trylock when modifying gtk-threads.c in
gnome-guile/guile-gtk.

I suppose this state of the art is OK transiently, but I really find
it useful to be able to use the "raw" thread library from my
applications (just as we have other scm_c_ interfaces for raw C level
access).  If you implement the thread plug-in interface we've talked
about, then maybe that data structure itself could also play the role
of this C level interface?

Let's call the data stucture scm_c_thread.  In this case,
gtk-threads.c would use a call:

  scm_c_thread.mutex_trylock ((scm_t_mutex *) mutex)

and Scheme level try-mutex would be implemented:

SCM
scm_try_mutex (SCM m)
{
  SCM_ASSERT (SCM_MUTEXP (m), m, SCM_ARG1, s_lock_mutex);
  return SCM_BOOL (scm_c_thread.mutex_trylock (SCM_MUTEX_DATA (m)));
}


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

Re: coop-pthreads + gtk-threads

[Mikael Djurfeldt]

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

> As you can guess, I discovered this when looking for
> copt_mutex_trylock when modifying gtk-threads.c in
> gnome-guile/guile-gtk.
> 
> I suppose this state of the art is OK transiently

Oops...  Looking closer at my own applications, I realize that I've
since long used a thread package independent C level interface.  My
own parts of gtk-threads.c use this interface (scm_mutex_*, scm_cond_*
etc; NOTE: these names were invented before the scm_c_ convention was
introduced).  The call to coop_mutex_trylock should of course be
scm_mutex_trylock.

However, to my consternation, this thread-independent API has been
deprecated in your latest change.  Note that if gtk-thread had used
the thread-independent API, and had this API been kept in the
coop-pthreads change, gtk-threads had now still been working together
with coop-pthreads...

Best,
Mikael


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