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 vari
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 the
>> 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 the
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 see
>> 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 wait4(2
> 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 this topic. Unix signals don't exactly work like
> hardwa
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.
Historically,
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 older systems, a second 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?
"Maybe." It depends on how portable you want to be.
Historically, "no": in some older systems, a second SIGCHLD delivered
when there's already
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
generate
11 matches
Mail list logo