[Tarantool-patches] [PATCH] Add a cancellation guard to cpipe flush callback
Leonid Vasiliev
lvasiliev at tarantool.org
Thu Dec 5 10:22:53 MSK 2019
On 12/3/19 9:02 PM, Konstantin Osipov wrote:
> * Leonid Vasiliev <lvasiliev at tarantool.org> [19/12/03 19:36]:
>> https://github.com/tarantool/tarantool/issues/4127
>> https://github.com/tarantool/tarantool/tree/lvasiliev/gh-4127-WAL-thread-stucks
>
> Looks like a great catch.
>
>> We need to set a thread cancellation guard, because
>> another thread may cancel the current thread
>> (write() is a cancellation point in ev_async_send)
>> and the activation of the ev_async watcher
>> through ev_async_send will fail.
>
> I still don't get from the explanation why it is relevant that
> ev_async_send mustn't fail?
The cause of why the ev_async_send mustn't fail is unwanted behavior of
the tarantool instance. For example: first thread flush cpipe input to a
endpoint output and go away while trying to call ev_async_send (write()
- cancellation point). Now stailq_empty(&endpoint->output) is false.
After that, another thread flush cpipe input to the same endpoint, but
it didn't try to call ev_async_send, because output_was_empty is false.
As result: a thread of endpoint->consumer didn't wake-up (blocked on
epoll_wait). The same situation described in
https://github.com/tarantool/tarantool/issues/4127:
at main thread:
from void wal_free(void):
cbus_stop_loop(&writer->wal_pipe);
if (cord_join(&writer->cord)) {...} // wait the "wal" thread
at "wal" thread:
don't try to call cbus_stop_loop_f (for the reasons described above)
blocked at epoll_wait()
>
>
More information about the Tarantool-patches
mailing list