Trouble with waitpid and Rust

[Matthew Dillon]

Er, what I meant to say, the thread doing the wait4(-1, ...) is returning
the pid that the second thread doing the wait4(pid, ...) was explicitly
waiting for.  So that second thread properly returns ECHILD.

So the question is who is doing the wait4(-1, ...)

-Matt

On Tue, Jul 11, 2017 at 9:25 AM, Matthew Dillon <dillon at backplane.com>
wrote:

> Ok, I'm not sure this is a bug in DragonFly.  When I ktrace -i the test
> program threaded, another thread is doing a wait4(-1, ...) at the same as
> the thread doing wait4(specific_pid, ...).  The specific pid is being
> repeated by the thread doing the wait4(-1, ...), so the thread doing the
> wait4(specific_pid, ...) doe sproperly return SIGCHLD in that situation.
>
> -Matt
>
> On Tue, Jul 11, 2017 at 9:13 AM, Matthew Dillon <dillon at backplane.com>
> wrote:
>
>> I assume you meant ECHILD?  That would definitely be a bug if there are
>> still children present after one exits.
>>
>> -Matt
>>
>> On Mon, Jul 10, 2017 at 8:29 AM, Imre Vadász <imrevdsz at gmail.com> wrote:
>>
>>> Ok, not related to SIGCHLD or anything like that. What I see when
>>> running that binary, is that 2 threads are blocking in wait() and when a
>>> child exit()s, one wait successfully returns. But the other one erronously
>>> reports SIGCHLD instead of continuing to block as would be expected. This
>>> definitely looks like a bug in the wait4 syscall, judging from the trace I
>>> got with "ktrace -i ./test-nix --test-threads 4" here.
>>>
>>>
>>> On Monday, July 10, 2017, Imre Vadász <imrevdsz at gmail.com> wrote:
>>>
>>>> Hi,
>>>> Did you verify that the child isn't just exiting before the parent
>>>> calls wait(), and getting reaped by a signal handler for SIGCHLD? This
>>>> should be easy to verify by running the binary with ktrace. In that case
>>>> getting ECHILD from waitpid() would be perfectly fine and could be treated
>>>> as success.
>>>> Regards, Imre
>>>>
>>>> On Monday, July 10, 2017, Michael Neumann <mneumann at ntecs.de> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 07/10/17 15:40, Michael Neumann wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I am trying to port some Rust libraries to DragonFly, specifically
>>>>> the
>>>>> > [nix] crate to access UN*X APIs from Rust.
>>>>>
>>>>> I think it's related to the problems that can occur when fork()ing a
>>>>> multi-threaded program, as described here:
>>>>>
>>>>>         http://www.linuxprogrammingblog.com/threads-and-fork-think-t
>>>>> wice-before-using-them
>>>>>
>>>>> Furthermore, I think this is similar to the "cargo" issue I am seeing,
>>>>> when running multi-threaded (it is forking and execve "rustc" and
>>>>> probably doing something in between... sometimes it hangs).
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>   Michael
>>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20170711/ed449643/attachment-0002.html>