Re: [Help-gnutls] Thread cancellation

[Scott Lamb]

Nikos Mavroyanopoulos wrote:
> > - Is gnutls cancellation-safe?
>
> No gnutls is not cancellation safe. I guess that there could be
> some memory leaks when cancelation is used. That could be changed
> though since the system calls used in gnutls are few, but I don't
> know if it is a good idea to make gnutls use libpthread.
>
> According to Werner Libgcrypt is also not cancelation safe, but
> this may change within the 1.2.x releases of libgcrypt (libgcrypt
> already depends on pthread due to some locking required).

libgcrypt depending on pthread is an argument for making gnutls use it, 
IMHO. If you're worried about extending its dependencies, gnutls -> 
libpthread is no worse than gnutls -> libgcrypt -> libpthread.

But if you just don't want to complicate things, no worries. I think I 
can accomplish what I want anyway (below).

> > - Similarly, is it exception-safe?
>
> No. gnutls is written in plain C, with no exceptions in mind.

I'd really like to be able to use cancellation, but I think I can 
accomplish it anyway. I can keep around another buffer layer between the 
underlying stream and TLS. Then I can alternate IO that goes on the 
underlying stream <-> buffer (with cancellation and exceptions enabled) 
and IO that goes on the buffer <-> gnutls (with cancellation disabled 
and no throwing of exceptions).

As a bonus, that means I don't need to convert exceptions to C errors 
and back. Which is good, because I think it's not possible to convert an 
arbitrary exception to C errors and back. (A consequence of C++ details 
I won't bore you with.) I'd have to have some extra code for every 
exception type that could pass through that layer, which kind of sucks.

Not quite as straightforward or efficient to mess with another buffer 
layer, but hopefully not too bad. (I guess when doing encryption, I 
probably shouldn't worry about the performance impact of some extra 
allocations and byte transfers, anyway; it's likely not even the same 
order of magnitude.)

Thanks,
Scott Lamb