On 19.08.2020 20:02, Roy Marples wrote:
> On 18/08/2020 20:52, Mouse wrote:
Perhaps it would need a new flavour of file descriptor, [...]
>>> Linux has apparently done this: pidfd (file descriptors representing
>>> a process). The idea is that you can pass them to various system
>>> call
On 18/08/2020 20:52, Mouse wrote:
Perhaps it would need a new flavour of file descriptor, [...]
Linux has apparently done this: pidfd (file descriptors representing
a process). The idea is that you can pass them to various system
call variants that otherwise take pids, without the risk that
>> Perhaps it would need a new flavour of file descriptor, [...]
> Linux has apparently done this: pidfd (file descriptors representing
> a process). The idea is that you can pass them to various system
> call variants that otherwise take pids, without the risk that the
> process has exited in
On Sat 15 Aug 2020 at 16:46:13 -0400, Mouse wrote:
> Personally, I don't like it; I think signals should be much like
> hardware interrupts in that a second instance happening before the
> first is serviced gets silently merged. If you want some sort of
> queued notification of child death, it
>> I don't understand what problem queued SIGCHLD was invented to
>> address.
> My impression is that it allows you to get notified of state changes
> of your child processes. If one signal could annonce several state
> changes, how would you know what these state changes are?
You'd call
> I don't understand what problem queued SIGCHLD was invented to address.
My impression is that it allows you to get notified of state changes of your
child processes. If one signal could annonce several state changes, how
would you know what these state changes are?
>>> When I install a SIGCHLD handler via sigaction() using SA_SIGINFO,
>>> is it guaranteed that my handler is called (at least) once per
>>> death-of-a-child?
>> "Maybe." It depends on how portable you want to be.
>> [...]
> While we're
On 2020-08-16 12:49, Johnny Billquist wrote:
On 2020-08-15 22:46, Mouse wrote:
When I install a SIGCHLD handler via sigaction() using SA_SIGINFO, is
it guaranteed that my handler is called (at least) once per
death-of-a-child?
"Maybe." It depends on how portable you want to be.
Hi
On 2020-08-15 22:46, Mouse wrote:
When I install a SIGCHLD handler via sigaction() using SA_SIGINFO, is
it guaranteed that my handler is called (at least) once per
death-of-a-child?
"Maybe." It depends on how portable you want to be.
Historically, "no": in some old
> When I install a SIGCHLD handler via sigaction() using SA_SIGINFO, is
> it guaranteed that my handler is called (at least) once per
> death-of-a-child?
"Maybe." It depends on how portable you want to be.
Historically, "no": in some older systems, a second S
Another question in the context of SIGCHLD:
When I install a SIGCHLD handler via sigaction() using SA_SIGINFO,
is it guaranteed that my handler is called (at least) once per
death-of-a-child? There is sentence in SUS
If SA_SIGINFO is set in sa_flags, then subsequent occurrences of sig
11 matches
Mail list logo
