guile-devel
[Top][All Lists]
Advanced

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

Re: crypt mutex


From: Andreas Voegele
Subject: Re: crypt mutex
Date: Tue, 24 Feb 2004 02:11:48 +0100
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux)

Mikael Djurfeldt <address@hidden> writes:

> Mikael Djurfeldt <address@hidden> writes:
>
>> Marius Vollmer <address@hidden> writes:
>>
>>>> In most cases, I would probably draw the line so that as much as
>>>> possible of the responsibility is left to the user with the
>>>> exceptions that 1. Guile should never segfault due to misuse in
>>>> this respect, and, 2. Guile need to have enough thread safety so
>>>> that it's reasonably convenient to write parallel programs.
>>>
>>> Yes, exactly my view.  Also, I would broaden point 1 a bit: we should
>>> also 'fix' functions that can not every be used in a threaded program
>>> without mutexes around them.  Like libc getpwent.  They might not
>>> segfault, but you can't use them anyway in a threaded program.
>>
>> But the normal case is *not* a threaded program.  The everyday program
>> can use crypt with a static buffer without mutexes.  A *threaded*
>> program needs mutexes...
>>
>> This is why I'm leaning towards a minimal policy---to design for the
>> common case of non-threaded programs, but leave the possibility open
>> to write parallel code without too much difficulty.
>
> Of course: If you by 'fix' mean making functions reentrant (that is:
> fixes without too much overhead), then I would agree.

I'd also prefer a minimal policy.  But what do you do if operating
system A provides the reentrant function foo_r() while operating
system B provides foo() only?  The Scheme procedure "foo" should
behave the same on both systems.

I think that there are four options:

1. Use foo_r() if available, otherwise protect foo() with a mutex
   internally.

2. Use foo() and tell the user to protect the Scheme procedure in
   threaded programs.  It doesn't make sense to use foo_r() in this
   scenario.

3. Provide two Scheme procedures: "foo" and a thread safe version
   "foo-r".  "foo-r" uses foo() and a mutex if foo_r() isn't
   available.

4. Provide two modules, a normal and a thread safe version.  A command
   line switch could be used to request thread safety.  IMHO this
   would be useful for stuff like the POSIX and networking procedures.




reply via email to

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