On 11/23/2016 10:43 PM, Lee Duncan wrote:
> On Nov 23, 2016, at 4:13 AM, Christian Seiler <[email protected]> 
> wrote:
>>
>> Hi,
>>
>> On 11/22/2016 11:43 PM, [email protected] wrote:
>>> static void catch_signal(int signo)
>>> [...]
>>>     switch (signo) {
>>>     case SIGTERM:
>>> -           iscsid_shutdown();
>>> +           iscsid_shutdown_and_cleanup();
>>>             exit(0);
>>>             break;
>>
>> I think this is not a good idea because most functions called
>> here will not be async signal safe, and you are calling them
>> from a signal handler. Beforehand this was not a problem since
>> iscsid_shutdown() is just a kill of the process group.
> 
> The signal is ignored while in the signal handler, and I expect
> not to get a SIGTERM storm. But perhaps you are right.

That's not what I meant when discussing async-signal
safety. My point was not about other signals interrupting
the signal handler itself - during the signal handler's
execution, they will be blocked, as you rightly stated.

My worry is the following scenario: the normal code is
calling a routine, and that routine gets interrupted by a
SIGTERM, then the data structures in memory could be in an
inconsistent state (because a part of the memory was changed,
but other parts haven't yet). In that case, the signal
handler would try to tear down an inconsistent data
structure.

> I see now (looking at the code), that I can just set the “exit
> the event loop” flag when SIGTERM is received. And it has
> the added benefit of being idempotent, so I don’t need to
> guard against receiving multiple signals.

Yes, I think that's the best solution.

Regards,
Christian

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to