[Help-gnutls] Re: avoiding signals completely

[Simon Josefsson]

Daniel Stenberg <daniel at haxx.se> writes:

> Hi gnutls hackers!
>
> I want to be able to use GnuTLS without ever having to bother with signals!
>
> We're using GnuTLS within libcurl and lots of people use it
> multi-threaded and then signals don't work properly and make no
> sense. Within libcurl itself we then make an effort to avoid them all
> over, but now we've fallen over a problem when GnuTLS sends (or rather
> is the cause of) a SIGPIPE.
>
> I've checked the _gnutls_io_write_buffered() function in both 1.4.4
> and 1.5.3 and there doesn't seem to be any means to disable the
> signal-generation.
>
> May I suggest that we at least add an option that avoids signals when
> using GnuTLS? It would be a matter of using the fourth send() argument
> on most platforms, and the SO_NOSIGPIPE socket option on some. We
> already do this magic in libcurl.

Hi!  I believe the design here is that GnuTLS should use the socket
and the send function as-is, and if that isn't acceptable, you can
write a replacement for send (which may simply be a dummy function
that call send with an additional flag) and tell GnuTLS to use it by
calling gnutls_transport_set_push_function.  So you can achieve what
you want today by using these hooks.

An API to set the fourth parameter to send might be acceptable; I'm
thinking something like:

gnutls_transport_set_send_flags (gnutls_session_t session, int flags);

Where the FLAGS variable would be used instead of 0 inside
_gnutls_io_write_buffered.  The variable should be 0 by default.

Some send flags have weird semantics, though, so the documentation for
the function would have to be clear on that, and should probably
suggest that the only known reasonable use of the function is for
MSG_NOSIGNAL.

However, setting socket options inside GnuTLS seems like a bad idea.
I believe the only POSIX dependency in libgnutls is for send and recv
(which can be replaced), and we don't want more POSIX dependencies.

> I would be willing to provide a patch if there's no major objections.
>
> Here's the full backtrace from Brendan Jurd who faced this problem:
>
> 	http://curl.haxx.se/mail/lib-2006-10/0321.html

It seems as if the right solution, when CURLOPT_NOSIGNAL is present,
would be for curl to set the socket options and to provide its own
send replacement for GnuTLS, which would call send with the
MSG_NOSIGNAL flag.

Alternatively, the application could deal with SIGPIPE.

/Simon