Re: Resizing hash tables in Guile

[Rob Browning]

Mikael Djurfeldt <address@hidden> writes:

> I agree.  When implementing the current thread safety I've
> encountered a cluster of very interesting problems.  I'll write up a
> small text about this, put in the workbook and post on the list.
> I'd say I can do this within a few weeks.  For example, I've
> discovered that the with-mutex construct we provide in threads.scm
> is of dubious utility.  It also seems hard to second-guess the
> "users" needs when trying to provide high-level thread-safety
> constructs in general.

Sorry I haven't had a chance to comment sooner, but I also feel that
we should probably let the user handle thread-safety.

Way back when I first started programming heavily with threads, I had
the naive impression that everything should "just be thread safe" :>
After a lot of hacking, I would have to say I was definitively wrong.
In my experience, the issues surrounding thread-safety and the
tradeoffs involved are too complex to be easily managed in a blanket
way.  As a trivial example, it can be frustrating if you're trying to
get high performance for a segment of code, to have no way to avoid
hundreds or thousands of mutex grabs when you already *know* that the
code segment in question is protected by some other means.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4