Daniel,
in fact in POSIX.1 errno is thread safe (see below).
So the thread safety issue that I'm taking about is not relevant.
I forget that errno is no more a global variable, but a special
function which store the error code per thread.
Regards
Sébastien
Redefinition of errno
In POSIX.1, errno is defined as an external global variable. But this
definition is unacceptable in a multithreaded environment, because its
use can result in nondeterministic results. The problem is that two or
more threads can encounter errors, all causing the same errno to be set.
Under these circumstances, a thread might end up checking errno after it
has already been updated by another thread.
To circumvent the resulting nondeterminism, POSIX.1c redefines errno as
a service that can access the per-thread error number as follows
(ISO/IEC 9945:1-1996, §2.4):
Some functions may provide the error number in a variable accessed
through the symbol errno. The symbol errno is defined by including the
header <errno.h>, as specified by the C Standard ... For each thread of
a process, the value of errno shall not be affected by function calls or
assignments to errno by other threads.
In addition, all POSIX.1c functions avoid using errno and, instead,
return the error number directly as the function return value, with a
return value of zero indicating that no error was detected. This
strategy is, in fact, being followed on a POSIX-wide basis for all new
functions.
>>> Daniel Stenberg <daniel_at_haxx.se> schrieb am 3/11/2011 um 19:02 in
Nachricht
<alpine.DEB.2.00.1103111858080.30016_at_tvnag.unkk.fr>:
> On Fri, 11 Mar 2011, Sebastien Fricker wrote:
>
>> But I'm guessing if it is not possible to get rid of errno: errno is
a
>> global error information that contain an error code but not
systematically
>> from the actual socket.
>
> What are you talking about?
>
> First, why would removing errno be a priority at all? errno is
defined by
> POSIX to be thread-safe *and* recv and send both are documented (and
proven)
> to provide additional error information in that variable after a
failure.
>
>> Using this variable makes libssh2 not thread safe.
>
> What platform do you claim this is true for?
>
>> I'm not sure if this code works.
>
> So you're suggesting we introduce code you don't know if it works?
(and yes,
>
> it will buffer overflow on many systems if the socket descriptor is
above
> 1024)
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2011-03-14