[libc] Add ppoll stub to match existing pselect stub. NFC

[sbc100]

This is mostly just for consistency and completeness.

[thiblahute]

Why are we defining function that won't work at runtime? In the GLib we have a check in meson.build to check if the function exists, and if it doesn't us poll() instead, but with that stub, we end up using ppoll and fail.

[sbc100]

Why are we defining function that won't work at runtime? In the GLib we have a check in meson.build to check if the function exists, and if it doesn't us poll() instead, but with that stub, we end up using ppoll and fail.

IIUC, this is how emscripten has worked since its inception. If you don't want the stubs we have a setting to disabled them: https://emscripten.org/docs/tools_reference/settings_reference.html#allow-unimplemented-syscalls

[kleisauke]

@thiblahute For GLib specifically, you might also be interested in this changeset:
GNOME/glib@2.88.0...kleisauke:wasm-vips-2.88.0
(see e.g. https://gist.github.com/kleisauke/acfa1c09522705efa5eb0541d2d00887)

This would also remove the need for the performance-unfriendly -sEMULATE_FUNCTION_POINTER_CASTS linker option.

[thiblahute]

@kleisauke You mean GNOME/glib@db7b8c4 or something else? This is not gonna get upstreamed, so I do not think it is an option. Have you measured the overhead of using -sEMULATE_FUNCTION_POINTER_CASTS ?

[kleisauke]

For poll() it's kleisauke/glib@bb3098f, which makes GPollFD APIs (e.g. g_wakeup_get_pollfd()) no-op. But you're right, these patches are not suitable for upstreaming, hence why I marked them as blocked here:
Stable release for wasm-vips

Have you measured the overhead of using -sEMULATE_FUNCTION_POINTER_CASTS ?

It's been over six years since I last measured this, so the results may no longer be accurate. Perhaps it was the same issue as observed in PR #26478.

[sbc100]

For ppoll specifically, I think we can followup by actually implement ppoll and pselect in emscripten (since we already support poll and select and these are basically the same modulo some signal handling stuff which emscripten doesn't support anyway).

I will probably do something very similar to what I did for pipe2 here: #26480