[Top][All Lists]
[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.