On Wed, Jun 12, 2013 at 10:56 PM, Lionel Cons <[email protected]> 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 -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
