On Thu, Jun 1, 2017 at 5:36 PM, Guido Classen wrote:
> I was curious how to catch SIGCHLD using trap and what behavior we should
> expect. Could you also provide a test for trap in conjunction with SIGCHLD.
I was about to ask the same question, until I realize that the SIGCHLD
handling behavior w
On 22 May 2017 at 19:43, Denys Vlasenko wrote:
>> I am not sure what is the right place to fix this. Any comment on this?
>> For me it works to suppress this signal on the corresponding poll() call.
>
> Well, SIGCHLD may have a trap, so, that would not be correct.
>
> Fixed in git, please try.
Tha
On 22 May 2017 at 19:43, Denys Vlasenko wrote:
>> I am not sure what is the right place to fix this. Any comment on this?
>> For me it works to suppress this signal on the corresponding poll() call.
>
> Well, SIGCHLD may have a trap, so, that would not be correct.
>
> Fixed in git, please try.
Tha
On Tue, May 9, 2017 at 11:14 AM, Guido Classen
wrote:
> Hi,
>
> I've observed some strange behavior in ash buildin "read" when
> a SIGCHLD arrives in current busybox.
>
> old behavior on busybox 1.24.2 ash (same behavior also on Debian bash and
> dash)
>
>sleep 1& read x
> => waits for ev
Hi,
I've observed some strange behavior in ash buildin "read" when
a SIGCHLD arrives in current busybox.
old behavior on busybox 1.24.2 ash (same behavior also on Debian bash and dash)
sleep 1& read x
=> waits for ever until input is given
new behavior on busybox
sleep 1& read x
[1
