guile-user
[Top][All Lists]
Advanced

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

Re: xchat-guile and threads


From: Linas Vepstas
Subject: Re: xchat-guile and threads
Date: Thu, 22 Jan 2009 22:08:28 -0600

2009/1/22 Neil Jerram <address@hidden>:
> in theory it is possible to
> call the SCM API concurrently from as many threads as you like, and
> libguile will use fine-grained locks to protect anything that needs
> protecting.  In practice, however, there are probably some bugs
> lurking...

Well, I'm happy to report that I don't think there
are many left.  There are one or two patches
that I submitted that unfortunately didn't make it
into 1.8.6 -- I resubmitted these, but I haven't
heard back from anyone indicating that they've
been applied (or that they've been explicitly
rejected either).

The biggest outstanding bug is the race
condition in the environment hash tables
that are updated when there are multiple
defines happening in parallel -- the symptom
is that some of the defines "don't stick",
as if they didn't happen.

I think Ludovic understands it well, and has
a good proposal on how to fix it. Unfortunately,
he's not describing an easy fix.

I looked at it but the problem seems to be deep,
with no easy quick fix/work-around. I contemplated
adding a brute force lock around scm_define(),
to serialize defines, but decided that this wasn't
enough, or wouldn't work, or wasn't a 100% solution.
(I don't quite remember the details -- I think the
problem is that other threads might still be reading
or even updating the ash table, outside of scm_define())

The other alternative, adding a lock on all hash table
access, would have been punitive in performance.
Or something like that.

Anyway, with the one or two patches, and a fix for
the define problem, would fix all of the bugs I've seen
-- I've carefully analyzed dozens, and haven't seen
any that are not due to one of these bugs.

--linas




reply via email to

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