3 ms·

The classic UNIX approach would of course be making FindFile non-reentrant and not thread-safe either, then later adding a FindFile_r which takes an void* * whe

The classic UNIX approach would of course be making FindFile non-reentrant and not thread-safe either, then later adding a FindFile_r which takes an void* * where FindFile_r will store some intermediate state that you need to free yourself except when an error occured, because when you free it then you get a double free. (However, not all UNIX systems have FindFile_r, and some of those instead have FindFile2 with slightly different semantics).

jstimpfle 8y ago
You are snarky, but I don't think it's warranted. Any examples of non-reentrant or thread-unsafe system calls in POSIX? There are a few library calls that have a cousin with an _r suffix in POSIX, but these are not system interfacing calls. Just don't use them if they don't match your requirements. Most of them aren't even non-reentrant or thread-unsafe, but simply lack an additional parameter for some use cases (the use cases mostly come when you program in object-oriented style). The one offender (not a system call, either) that I know from the top of my head is strtok() which is of course terrible, but why would you use it?
- Someone 8y ago
  ”There are a few library calls that have a cousin with an _r suffix in POSIX, but these are not system interfacing calls.” Neither are most Windows functions. FindFirstFile, for example, is defined in kernel32.dll, and calls through to ntdll.dll, and eventually makes system calls such as NtOpenDirectoryObject and NtQueryDirectoryObject. What IMO matters is the usability of the stable API. It doesn’t matter whether that is the kernel interface or not.
  - jstimpfle 8y ago
    Yes. The distinction I made was meant to be between calls that end up calling into the system and ones that do not (like strtok()). I agree with what you say and my statement was exactly that the stable APIs into the system offered by POSX are mostly unproblematic.
- manwe150 8y ago
  Probably true, but there is in fact the apropos readdir function, which does have a readdir_r variant to address thread safety issues (now apparently deprecated due to other unrelated design issues). So it seems the joke’s on us. Getting API design right is _hard_.
deleted 8y ago
[deleted]

jstimpfle 8y ago

You are snarky, but I don't think it's warranted. Any examples of non-reentrant or thread-unsafe system calls in POSIX? There are a few library calls that have a cousin with an _r suffix in POSIX, but these are not system interfacing calls. Just don't use them if they don't match your requirements. Most of them aren't even non-reentrant or thread-unsafe, but simply lack an additional parameter for some use cases (the use cases mostly come when you program in object-oriented style). The one offender (not a system call, either) that I know from the top of my head is strtok() which is of course terrible, but why would you use it?

Someone 8y ago
”There are a few library calls that have a cousin with an _r suffix in POSIX, but these are not system interfacing calls.” Neither are most Windows functions. FindFirstFile, for example, is defined in kernel32.dll, and calls through to ntdll.dll, and eventually makes system calls such as NtOpenDirectoryObject and NtQueryDirectoryObject. What IMO matters is the usability of the stable API. It doesn’t matter whether that is the kernel interface or not.
- jstimpfle 8y ago
  Yes. The distinction I made was meant to be between calls that end up calling into the system and ones that do not (like strtok()). I agree with what you say and my statement was exactly that the stable APIs into the system offered by POSX are mostly unproblematic.
manwe150 8y ago
Probably true, but there is in fact the apropos readdir function, which does have a readdir_r variant to address thread safety issues (now apparently deprecated due to other unrelated design issues). So it seems the joke’s on us. Getting API design right is _hard_.

deleted 8y ago

[deleted]