Hacker News Reader

Comment by kazinator | Hacker News Reader

signals, forking, and simple things like chdir.

A huge area that is broken w.r.t. threading is the whole internationalization stack: setlocale and all.

What if I want to write a server such that each request is executed in a potentially different locale (because it services globally distributed users?)

View on HN

Ah yes, I was thinking about the system call interfaces but if we start looking at libc damn near nothing was reentrant until relatively recently (the late 90s and early 00s count as recent right? ... right?)

Just take a gander at all those _r functions where an extra parameter needed to be added for reentrancy.

Some of them turned out to be hyper-corrective duds, like readdir_r. No need for that one, since the buffer it needs can be allocated in the DIR object. You'd never want multiple threads concurrently doing readdir_r from the same DIR stream; there is no credible use case for it. (Or, maybe, optimization? Since it can store the dirent-s directly into some space designated by the caller, eliminating a copy operation from a program that wants to retain all those dirent-s.)

Is this because, as I recall, a DIR object is opaque while a FILE is not? Allowing the former to be expanded without breaking the API?

edit: Nevermind, that shouldn't matter should it? The important thing is that they're both by reference.

FILE can be opaque. Some implementations made the (arguable) mistake of implementing e.g. fileno() as a macro that accesses FILE internals, and this means they can't change that layout without breaking libc ABI of existing programs. But you can implement all POSIX stdio FILE APIs with an opaque FILE.

What if I want to write a server such that each request is executed in a potentially different locale?

You can use uselocale() to install a thread-specific locale.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/us...

That's useful to know; so they finally patched this, some ten years ago now.

Then your thread better only execute one request at a time and carry through every operation involved in that request. Works fine in PHP, not fine in most performant and even most non performant web contexts.

But that's fine. For example, you pull the thread from a pool and bind it to the request. As part of this, the thread pulls the locale object from the request and attaches to it. It services that request, and then returns to the pool. Next time it is pulled from the pool it gets a request in a different locale.

Other disciplines are possible. E.g. some operation involving multiple locales, all in one thread, can just do the uselocale calls as needed.

That's not fine, because processing a single request often involves waiting on some I/O, and the thread can service (a part of) another request in the meantime. Which is what modern event loop driven servers do - but this doesn't play well with thread locals, or abstractions implemented on top of them, because now your single physical thread effectively runs multiple cooperatively scheduled logical threads/requests.

haimez said this already, but I wanted to phrase it another way:

This only works if your not executing multiple requests in the same thread, ie: using non-blocking IO.

Even if you're using non-blocking or asynchronous IO there's always going to be a point at which you switch to the context of a particular request in order to handle it, and that's the point at which you can also switch locales if you want to handle it in a locale-specific way.

IEEE Std 1003.1-2017 actually specifies chdir() as thread-safe (obviously in the sense that it is atomic but influences all process' threads).

It strikes me as particularly weird as there are notionally POSIX-conformant OSes that implement it in a way that is not atomic.

Thread safety is not the issue. The issue is that multiple threads may want multiple different working directories simultaneously, for different work items. But there is one working directory for the process. This problem is partly alleviated by the ...at() family of system calls, of course.

It's comments like this which make me think that the state stack should be on the connection handle rather than on a worker unit... or maybe they're the same thing.

Then you don't use multithreading at all rather than conclude it's broken?

Reply on news.ycombinator.com