[ast-developers] Using |signalfd()| ... / was: Re: ast-ksh 2013-06-11 alpha

[Roland Mainz]

On Wed, Jun 12, 2013 at 10:56 PM, Lionel Cons
<lionelcons1972 at googlemail.com> wrote:
[snip]

Did anyone thought about the idea of using signalfd() instead?

Yes... but the problem is that |signalfd()| is Linux-specific and it
took the Linux people some iterations until it became useable... so
this is AFAIK not the answer...
... but IMO the |signalfd()| concept can point into the right direction...

... question to Glenn: Can I assume that |ftruncate()| is available
and working on all platforms supported by AST ?

The basic idea is to use two fds (at the beginning pointing to 2 r/w
files in /tmp (|unlink()|'ed to make them invisible)). The first is
used by the signal handler to |write()| (raw, NOT sfio wrapped... but
incl. the usual |EINTR| loop) the siginfo structures to a file. Once
the shell wants to check for signals it uses aso to swap the two |int|
variables with the fds and then starts using |read()| on the fd
obtained in a loop to read the siginfo data. Once all siginfo data
have been processed the file gets truncated via |ftruncate()| and the
function exists. The next cycle will swap the fds again etc. etc.
AFAIK this should be async-signal-safe because the signal handlers
_always_ writes to an fd which is currently not being |read()| from...
right ?

David/Glenn: What do you think about the idea ? AFAIK it would avoid
the involvement of the memory allocator and the issues with
async-signal-safeness...

... the alternative would be to write an abstracted fifo queue
implementation which is async-signal-safe and put it into libast (and
fix the allocator issues with async signals) ... question is whether
this is possible...

----

Bye,
Roland