Only handle robust mutexes and sigfastblock on exec and exit for native FreeBSD ABIs

[kib]

Summary

[!amd64 will follow later]

Requested by: dchagin

[dchagin]

it would be nice to eliminate umtx_thread_exit() call from linux_exit().
I'm AFK till monday, went to pick up the boat after repair, so im ok with the proposed change

[kib]

No need to call umtx_cleanup_thread() from cloudabi/linux thread exit syscalls either

[dchagin]

thanks!

[markj]

Looks ok, but why? Now in the native case we converted direct function calls to an indirect call, but umtx and sigfastblock already do nothing in the !native case.

[kib]

In D30987#698336, @markj wrote:

Looks ok, but why? Now in the native case we converted direct function calls to an indirect call, but umtx and sigfastblock already do nothing in the !native case.

It was requested by dchagin. Obvious but vague reason is to not call freebsd-abi specific methods on other ABIs. But my guess is that linuxolator would get robust mutexes rework that might reuse parts of native code, including the structures pointed from struct thread. Then calling freebsd-native directly would be problematic.

[markj]

In D30987#698405, @kib wrote:

In D30987#698336, @markj wrote:

Looks ok, but why? Now in the native case we converted direct function calls to an indirect call, but umtx and sigfastblock already do nothing in the !native case.

It was requested by dchagin. Obvious but vague reason is to not call freebsd-abi specific methods on other ABIs. But my guess is that linuxolator would get robust mutexes rework that might reuse parts of native code, including the structures pointed from struct thread. Then calling freebsd-native directly would be problematic.

It makes some sense to hide sigfastblock this way, but umtx is not really tied to any particular ABI as I understand it. So it feels to me that the umtx code should internally handle any extensions required to support the futex implementation. Probably I'm just quibbling.

[kib]

In D30987#698526, @markj wrote:

In D30987#698405, @kib wrote:

In D30987#698336, @markj wrote:

Looks ok, but why? Now in the native case we converted direct function calls to an indirect call, but umtx and sigfastblock already do nothing in the !native case.

It was requested by dchagin. Obvious but vague reason is to not call freebsd-abi specific methods on other ABIs. But my guess is that linuxolator would get robust mutexes rework that might reuse parts of native code, including the structures pointed from struct thread. Then calling freebsd-native directly would be problematic.

It makes some sense to hide sigfastblock this way, but umtx is not really tied to any particular ABI as I understand it. So it feels to me that the umtx code should internally handle any extensions required to support the futex implementation. Probably I'm just quibbling.

IMO umtx is very FreeBSD-specific. But I wonder what Dmitry would end up with.

[dchagin]

In D30987#698633, @kib wrote:

In D30987#698526, @markj wrote:

In D30987#698405, @kib wrote:

In D30987#698336, @markj wrote:

Looks ok, but why? Now in the native case we converted direct function calls to an indirect call, but umtx and sigfastblock already do nothing in the !native case.

It was requested by dchagin. Obvious but vague reason is to not call freebsd-abi specific methods on other ABIs. But my guess is that linuxolator would get robust mutexes rework that might reuse parts of native code, including the structures pointed from struct thread. Then calling freebsd-native directly would be problematic.

It makes some sense to hide sigfastblock this way, but umtx is not really tied to any particular ABI as I understand it. So it feels to me that the umtx code should internally handle any extensions required to support the futex implementation. Probably I'm just quibbling.

IMO umtx is very FreeBSD-specific. But I wonder what Dmitry would end up with.

well, for now I rewrote the futex code with umtx and started writing new pi code.