Re: thread safe functions

[Andy Wingo <wingo@pobox.com>]

Hi Ken,

You mailed a long time ago with some threadsafety issues and I think
I've finally gotten to all of the ones you have mentioned.

You made good points regarding memory ordering also, but I'm going to
let that slide for now, as it didn't have specific bugs.  Should you be
motivated to review further, please send separate mails.  I know that
sounds silly but it looks less daunting that way.

On Thu 10 Feb 2011 23:19, Andy Wingo <wingo@pobox.com> writes:

> On Sun 29 Aug 2010 03:33, Ken Raeburn <raeburn@raeburn.org> writes:
>
>> I was starting to look through the port code for this, but got
>> distracted by scm_ptobs, a pointer which appears to be dynamically
>> reallocated as needed when scm_make_port_type is called.  Which means
>> every function that reads it should be locking the same mutex used when
>> updating it; in this case, that appears to be the generic "critical
>> section" stuff, and it looks like we're not doing that.
>
> Yeah, and it is exported to users of libguile.  Fun, no?  I added a
> comment to the header about its impending deprecation, but that's all I
> have time for right now.

Actually this bug is still present.

>> smob.c: I don't think tramp_weak_map is adequately protected, but I'm
>> not certain.

Fixed.

>> srcprop.c: scm_source_whash isn't protected; it also appears to be
>> exposed by the name "source-whash" to Scheme code, which wouldn't be
>> able to use a mutex defined and used purely in the C code.

Fixed also.

>> struct.c: Even calling struct-vtable-name can cause a hash table entry
>> to be created, it appears.  So that's not thread-safe, never mind the
>> call to actually change the name.

Fixed to a degree earlier; fixed more definitively now.

Happy hacking,

Andy
-- 
http://wingolog.org/