thread: Ignore errors when copying out during thr_exit()

[markj]

Summary

It does not seem reasonable to return to userspace after calling
umtx_thread_exit().

This is in preparation for annotating copyin() and related functions
with __result_use_check.

[olce]

Your change makes me note that we may want thr_exit(2) to return some value, especially given it's documented that it can return to userland when called on the last process' thread.

[markj]

In D43143#983377, @olce wrote:

Your change makes me note that we may want thr_exit(2) to return some value, especially given it's documented that it can return to userland when called on the last process' thread.

What useful value could it return?

I note that libthr appears to avoid calling thr_exit() on the last thread, exit_thread() counts the number of threads left and calls exit() directly from the last one.

[olce]

In D43143#983444, @markj wrote:

What useful value could it return?

I note that libthr appears to avoid calling thr_exit() on the last thread, exit_thread() counts the number of threads left and calls exit() directly from the last one.

E.g., it could return EBUSY for the last thread, EFAULT if it cannot process state (store 1 or fail in kern_umtx_wake()), else 0. libthr calls it correctly but as a system call, isn't it part of the public interface (even if the man page says it is to be used to implement threading)? In which case, returning a status would IMHO be better than silently failing. This wouldn't change the ABI, would it?

[markj]

This wouldn't change the ABI, would it?

Adding a return value changes the API at least. Any code that assumes that a return from thr_exit() means that the caller is the last thread in the proc, is now potentially broken.

[olce]

In D43143#983809, @markj wrote:

Adding a return value changes the API at least. Any code that assumes that a return from thr_exit() means that the caller is the last thread in the proc, is now potentially broken.

You're right, this is an unfortunate incompatibility, and the behavior you describe seems to be convenient enough that it could plausibly be used, even if I would expect a threading library to know whether it is operating in the main thread or not (but then, a similar argument for state could be made).

Too bad it's like that. So I'm withdrawing that note. Thanks.