POSIX API is not portable across arches

[yashi]

Is your enhancement proposal related to a problem? Please describe.

I believe that mentioning POSIX API in The POSIX architecture is a +1.

Especially the code like this:

while(1) {
    do_some();
    usleep(1);
}

This code works with POSIX API but it doesn't on native_posix. It is because, as I assume, that

• on Non POSIX arch with POSIX API, usleep() is k_usleep() and it's a scheduling point.
• on POSIX arch, usleep() is just a native function and it's not a scheduling point for Zephyr.

Describe the solution you'd like
Mention sleep() and usleep() in POSIX Support or The POSIX architecture with note about scheduling point.

[cfriedt]

There are a few changes to the POSIX subsystem planned, and yeah, you're right that there is some inconsistency between ARCH_POSIX and POSIX_API w.r.t. usleep. In the latter, it's possible that a short sleep will not trigger the scheduler (by calling k_busy_wait()).

The above is partially a workaround for a lack of high-precision timers, rather than being tick-based. The POSIX sleep calls should really lean on hardware timers rather than being tick-based.

The topic of high-precision timers / a real-time clock API will likely be increasingly important in the near term, as we need to resolve some layering violations when Zephyr switches to PicoLibC.

cc @stephanosio @keith-packard

Also somewhat relevant to #51978

For now, I'll document this inconsistency. Thanks for bringing it up @yashi

[cfriedt]

Actually, I'm going to categorize this as a bug. The (Linux) man page is pretty clear that it is broken.

https://man7.org/linux/man-pages/man3/usleep.3.html

PR imminent.

[cfriedt]

Also, when running on ARCH_POSIX we do not have control over POSIX API functions, since they are all native to the host OS. This is something that should be resolved in the LTSv3 POSIX Roadmap #51211