tevent_loop_wait() never finishes

[Pavel Březina]

On 06/24/2013 03:39 PM, Simo wrote:
> On 06/24/2013 08:52 AM, Pavel Březina wrote:
>> Hi,
>> I've run across a problem where I don't have any custom event handlers
>> registered with tevent, but the program gets stuck in tevent_loop_wait().
>>
>> When I print out the event context, I see there is still one fd
>> handler registered. It is sig_pipe_handler() that is created
>> internally by tevent at tevent_signal.c:254.
>>
>> (gdb) p dyndns_test_ctx->tctx->ev[0]
>> $11 = {ops = 0x3e14a0aca0, fd_events = 0x62c9b0, timer_events = 0x0,
>> immediate_events = 0x0, signal_events = 0x0, additional_data =
>> 0x622890, pipe_fde = 0x62c9b0, pipe_fds = {12, 14}, debug_ops = {debug
>> = 0,
>>     context = 0x0}, nesting = {allowed = false, level = 0, hook_fn =
>> 0, hook_private = 0x0}, tracing = {callback = 0, private_data = 0x0}}
>>
>> (gdb) p dyndns_test_ctx->tctx->ev[0]
>> $6 = {ops = 0x3e14a0aca0, fd_events = 0x62c9b0, timer_events = 0x0,
>> immediate_events = 0x0, signal_events = 0x0, additional_data =
>> 0x622890, pipe_fde = 0x62c9b0, pipe_fds = {12, 14}, debug_ops = {debug
>> = 0,
>>     context = 0x0}, nesting = {allowed = false, level = 0, hook_fn =
>> 0, hook_private = 0x0}, tracing = {callback = 0, private_data = 0x0}}
>>
>> What is the purpose of this signal?
>
> It is used to process signal events outside of the actual signal handler
> where the amount of processing and systems call that can be used is
> limited.
> When a signal comes tevent simply writes to the pipe so that as soon as
> control is returned to the event loop it sees that a read is possible on
> the fd and calls the correct code to deal with the reported signal.

If I understand this correctly, the sig_pipe_handler is useful only when 
there exist any signal handler. So when there is no signal handler, the 
sig_pipe_handler should be removed so it does not prevents 
tevent_loop_wait() to finish, right?

>
>> Is there any way how to remove it?
>
> Apparently the only place where this happens is when the event context
> is freed or re-initialized.
>
>> Also why ev->fd_events->prev == ev->fd_events?
> I am not sure about this, I do not see where or why this happens.
>
> Simo.

Thanks,
Pavel.