nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] Signal safety Issue


From: Benno Schulenberg
Subject: Re: [Nano-devel] Signal safety Issue
Date: Sun, 29 Jul 2018 19:49:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

Hello Daniel,

Op 27-07-18 om 12:06 schreef Daniel Kozovsky:
> In ‘nano.c‘ line 1294 in signal handler ‘do_continue‘ is used function
> ungetch(KEY_FLUSH). I believe that this function is not asynchronous-safe, so
> it should not be used in signal handler.

Thanks for reporting...  You frightened me.  :)

Yes, one might think putting back a character in a queue will be
an async-unsafe operation: the get() and unget() routines updating
variables at the exact same time.

But when I look in the latest ncurses-6.1 tarball, then in the
file ncurses/base/lib_ungetch.c, there is this:

NCURSES_EXPORT(int)
ungetch(int ch)
{
    return safe_ungetch(CURRENT_SCREEN, ch);
}

It looks like ungetch() has been implemented in a safe manner.

And just thinking about it a little, I think it should be possible
to implement a fifo in an async-safe manner without much effort,
as the get() and unget() operations work on different ends of the
queue.  Only when head and tail are equal, some care must be taken.

But I haven't studied the code in detail, so I don't know whether
the code is in fact async-safe.  But from the naming, it looks like
it is.  If you think differently, do let us know.

> Also in text.c line 1107 in signal handler ‘cancel_command‘ is used function
> nperror("kill"). This function calls function perror, which is
> asynchronous-unsafe, so this also should not be used in signal handler.

You are right, of course.  Let's see if we can get rid of the
nperror() call...  The kill(2) function can return one of three
erros:  EINVAL -- the signal is invalid.  But SIGKILL is a valid
signal, so this won't happen.  EPERM -- we don't have permission
to terminate the process.  But we created the process ourselves,
so we must have this permission, so this shouldn't be a problem
either.  ESRCH -- the process does not exist.  Well, if that is
the case, then there is no problem, because what we want is for
the process to stop existing.  So... I think we can safely ignore
the return value of kill() and not print anything at all when it
does happen to return -1.  Would you agree?

Thanks again for reporting.

Benno

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]