4 ms·
Unfortunately std::thread is not as capable as pthreads. For example, std::thread has no facilities for controlling the stack size or signal mask. Whenever I u
by ridiculous_fish 9y ago
Unfortunately std::thread is not as capable as pthreads. For example, std::thread has no facilities for controlling the stack size or signal mask.
Whenever I use channels, I find I need them to synchronize with each other. For example, I have a Go data structure with a write channel and a separate read channel; how do I avoid a read-after-write hazard?
The simplest solution is to make them the same channel that ships closures, to ensure requests are processed in-order. But then why not just make all channels ship closures, like libdispatch...
- shaklee3 9y agoYou can get the underlying pthread pointer if you want.
- ridiculous_fish 9y agoUnfortunately pthread attributes need to be set at creation time, so by the time you have a pthread pointer it's too late.
- to3m 9y agopthread_sigmask always operates on the current thread.
- ridiculous_fish 9y agoThe usual technique is to set the pthread sigmask and then spawn the thread, to avoid the obvious race. But it's risky to assume that `std::thread` won't manipulate the sigmask by itself.
- to3m 9y agoInteresting point about the stack size! As for the signal mask, I'm pretty sure you can just set that using pthreads, and it will apply to the current thread. This is certainly true for the pthreads thread name, which is as deeply as I've investigated myself... the C++ threads library isn't magic. It's just a wrapper round what you'd expect.