[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

coop-pthreads + gtk-threads

From: Mikael Djurfeldt
Subject: coop-pthreads + gtk-threads
Date: Thu, 07 Nov 2002 10:47:18 +0100


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

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_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)));

reply via email to

[Prev in Thread] Current Thread [Next in Thread]