This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

COOP threads now Linux threads safe + GTk threading library


The current CVS has (finally!) become compatible with Linux POSIX
threads.

Previously, any attempt at creating a COOP thread (Guile's custom
threads) in an application linked with Linux POSIX threads resultet in
a segmentation fault.  This was because of the way Linux pthreads
identifies a thread through the stack pointer.

Now, a workaround for this is enabled on Linux systems.

(Note also the availability of scm_spawn_thread which an application
 can use to create COOP threads from C, and scm_internal_select by
 which an application can do non-blocking I/O COOP-compatibly.)

Finally, here's a copy of a recent announcement about a library which
enables running a GTk handler in a COOP-thread:



I've made the frist version of a new Guile module:

http://www.nada.kth.se/~mdj/guile-gtkthreads/guile-gtkthreads-0.1.0.tar.gz

  or

cvs -z 9 -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/guile \
  checkout guile/guile-gtkthreads


Here's the README:

This is a library for people who are using guile-gtk but prefer using
threads instead of an event loop.


Dependencies
------------

This library needs to be compiled with:

* libguile >2000-03-29 with thread support (--with-threads)

* guile-gtk


Getting started
---------------

  (use-modules (gtk gtk) (gtk threads))
  (define w (gtk-window-new 'toplevel))
  (gtk-widget-show w)
  (begin-thread (gtk-main)) ; this becomes the handler thread


Known problems
--------------

If the gtk commands above are placed after the handler thread is
started, nothing happens.  The reason is that the handler thread is
waiting for events inside a `select'.  Executing gtk commands won't
kick it out of this select.

guile-gtkthreads will be upgraded to handle such situations better:

The handler thread will be split in two: one event loop and one io
listener.  The io listener sits in a select and signals a condition
variable to get the event loop to handle events.  Every gtk command
will also signal the event loop.

There will still be the problem that a gtk command can set up new io
sources.  The io loop won't know until it has processed next event
among the "old" io sources.  If you can think of a solution to this
problem, I'm very interested (mailto:djurfeldt@nada.kth.se).

Until these problems has been fixed, guile-gtkthreads is still useful
if you make sure to start the handler late enough and make sure
yourself to call gtk to process any new events originating in new gtk
command calls.


Bugs reports
------------

Send bug reports to bug-guile@gnu.org.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]