Benjamin Sugars wrote:
> > This is distinctly non-trivial.
>
> And ultimately fruitless too, I fear. Which is why the programmer will
> still need to guard entry into critical sections.
And with enough of these in place any concurrency will vanish, in which
case, why bother threading at all? Threads and locking are *difficult* to
get right, even in a language that supports them (such as Java) - see
http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html
http://www.javaworld.com/javaworld/jw-03-2001/jw-0323-letters.html
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
for an example of a common Java paradigm that is mentioned in lots of the
literature and books, but is in fact broken - and remember, unlike Perl,
Java actually *has* synchronisation support in the language *and* a defined
virtual machine memory model.
We might actually be better expending effort in providing a proper event
loop in perl - this is more likely to be achievable within the strictures of
the existing perl5 implementation, and if we are going to end up locking
everything anyway, it may not end up being any slower.
> The thing that I'm worried about is that with a lot of the perl runtime
> dependent on external libc's and the like, one doesn't even know where the
> critical sections are, at least not in a cross-platform sense.
Not to mention the fact that any such critical sections and/or stored state
aren't part of the defined interfaces of these libraries, and are liable to
change from one patch to the next, let alone from one release to the next.
Alan Burlison
