libthr: Robust tryjoin test

[aokblast]

Summary

We cannot actually rely on a status (finish) before thr_exit. The
thread needs the kernel signal status=1 to userspace. Before that,
any tryjoin fails. The previous one works as we sleep 1 and should be
enough for normal case.

[kib]

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

[kib]

In D60832#1395064, @kib wrote:

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

D60838

[aokblast]

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

[kib]

In D60832#1395514, @aokblast wrote:

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

I do not understand what do you intended to say by this sentence.

[aokblast]

In D60832#1395914, @kib wrote:

In D60832#1395514, @aokblast wrote:

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

I do not understand what do you intended to say by this sentence.

I mean this robustness change is needed as we are testing pthread_tryjoin_np, which should not query status by using kinfo_proc.

[kib]

In D60832#1397005, @aokblast wrote:

In D60832#1395914, @kib wrote:

In D60832#1395514, @aokblast wrote:

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

I do not understand what do you intended to say by this sentence.

I mean this robustness change is needed as we are testing pthread_tryjoin_np, which should not query status by using kinfo_proc.

I still do not understand why should it not. Using kinfo would make the test more precise IMO, But I do not intend to block this change.

[markj]

In D60832#1397040, @kib wrote:

In D60832#1397005, @aokblast wrote:

In D60832#1395914, @kib wrote:

In D60832#1395514, @aokblast wrote:

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

I do not understand what do you intended to say by this sentence.

I mean this robustness change is needed as we are testing pthread_tryjoin_np, which should not query status by using kinfo_proc.

I still do not understand why should it not. Using kinfo would make the test more precise IMO, But I do not intend to block this change.

I also do not really understand. It seems fine to use kinfo. See tests/sys/kern/procdesc.c:wait_for_naptime() for an example. It is just an alternative method to avoid polling while you are waiting for thr_fun() to wake up.

[markj]

In D60832#1397587, @markj wrote:

I also do not really understand.

I guess, it's somewhat dubious to assume that pthreads and kernel threads map 1:1 with each other? I think that is probably still reasonable within a libthr test, but ok.

[aokblast]

In D60832#1397587, @markj wrote:

In D60832#1397040, @kib wrote:

In D60832#1397005, @aokblast wrote:

In D60832#1395914, @kib wrote:

In D60832#1395514, @aokblast wrote:

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

I do not understand what do you intended to say by this sentence.

I mean this robustness change is needed as we are testing pthread_tryjoin_np, which should not query status by using kinfo_proc.

I still do not understand why should it not. Using kinfo would make the test more precise IMO, But I do not intend to block this change.

I also do not really understand. It seems fine to use kinfo. See tests/sys/kern/procdesc.c:wait_for_naptime() for an example. It is just an alternative method to avoid polling while you are waiting for thr_fun() to wake up.

Wouldn't wait_for_naptime still poll on something?

[kib]

In D60832#1397713, @aokblast wrote:

In D60832#1397587, @markj wrote:

In D60832#1397040, @kib wrote:

In D60832#1397005, @aokblast wrote:

In D60832#1395914, @kib wrote:

In D60832#1395514, @aokblast wrote:

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

I do not understand what do you intended to say by this sentence.

I mean this robustness change is needed as we are testing pthread_tryjoin_np, which should not query status by using kinfo_proc.

I still do not understand why should it not. Using kinfo would make the test more precise IMO, But I do not intend to block this change.

I also do not really understand. It seems fine to use kinfo. See tests/sys/kern/procdesc.c:wait_for_naptime() for an example. It is just an alternative method to avoid polling while you are waiting for thr_fun() to wake up.

Wouldn't wait_for_naptime still poll on something?

Yes but it is an external channel for the information, so you are not affected by a possible bug in the tested function.

[aokblast]

In D60832#1397713, @aokblast wrote:

In D60832#1397587, @markj wrote:

In D60832#1397040, @kib wrote:

In D60832#1397005, @aokblast wrote:

In D60832#1395914, @kib wrote:

In D60832#1395514, @aokblast wrote:

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

I do not understand what do you intended to say by this sentence.

I mean this robustness change is needed as we are testing pthread_tryjoin_np, which should not query status by using kinfo_proc.

I still do not understand why should it not. Using kinfo would make the test more precise IMO, But I do not intend to block this change.

I also do not really understand. It seems fine to use kinfo. See tests/sys/kern/procdesc.c:wait_for_naptime() for an example. It is just an alternative method to avoid polling while you are waiting for thr_fun() to wake up.

Wouldn't wait_for_naptime still poll on something?

Thanks! Committed and do similar thing for what we have on wait_for_naptime

[aokblast]

Merged