search

bitwiseworks / libc

LIBC Next (kLIBC fork)
9 stars 4 forks source link

socketpair returns ENOTSOCK #94

Closed dmik closed 3 years ago

dmik commented 3 years ago

I can observe in bitwiseworks/qtwebengine-chromium-os2#12 that calling socketpair (by libevent, to implement a socket based event pump) sometimes fails with ENOTSOCK for no reason. This error code comes to LIBC directly from the socketpair implementation in the OS/2 TCP/IP stack (TCPIP32.DLL) and LIBC simply passes it over to the caller. This expectedly breaks normal Chromium execution because it can't live w/o a socket channel.

Practice shows that simply retrying the socketpair call in such a case cures it. (Which makes this hack similar to what we do for OS/2 TCP/IP select and EBADF/EFAULT, see bitwiseworks/libcx#85). We should incorporate such a retrial into the LIBC socketpair implementation.

dmik commented 3 years ago

Note that LIBC socketpair (a wrapper around TCP/IP socketpair) is not a LIBC export. Instead, it lives in a static library libsocket as well as libc_dll so that it's linked to any app using LIBC. Just for the record. I have no idea why it was done this way but it basically means that the wrapper code is duplicated in any EXE and it will have to be recompiled in order to incorporate the fix. Simply replacing the LIBC DLL won/t help.

dryeo commented 3 years ago

Back in the EMX days, you had to link with -lsocket for any network code. kLIBC removed the need to link with it and I thought it was more of a wrapper now. I assume that EMX did it that way due to where ever they got their libc code from. Solaris for example still uses -lsocket I believe.

dmik commented 3 years ago

Yes, I even remember that. Not needed in case of kLIBC because, as I mentioned, libsocket stuff is now part of libc_dll (which is dragged in by gcc by default unless -nostdlib is given). My guess is that Knut left it as statics in order to be able to use the same kLIBC DLL with different TCP/IP stacks by just changing libsocket in question. However, from what I see now, the build of kLIBC for older TCP/IP includes libc_dll as well which means you will get other versions by just linking that... From this POV, having this stuff as static is just a waste of code segment space.