zirias@
Developer
This "special" recent thread:
made me think about a potential portability issue.
Some time ago, I wrote an event-driven network service for my own use, built around pselect(2). It's single threaded by design and should never block (except, of course, on the pselect(2) call in the center of the event loop).
Then, I needed some APIs (namely getnameinfo(3) and syslog(3)) that lack an async version, so I built a little thread pool to delegate the potentially blocking stuff to different threads, thus "faking" async behavior.
This works perfectly fine on Linux and FreeBSD (didn't test any other POSIX systems), but both default to a 1:1 thread model: all threads are kernel-level threads. Now, what if the implementation would use N:M or even N:1 (PULT) threads? Is my assumption correct that, in that case, a blocking syscall would block my whole process? IOW, should I add
C - When pthreads will work properly on FreeBSD?
Last time when I have tested FreeBSD a few years ago, threads created with pthread was still not able to utilize multiple CPU cores. This made me to permanently halt all software development for BSD. Currently however I plan to restart some development for FreeBSD, and release binaries for BSD...
forums.freebsd.org
Some time ago, I wrote an event-driven network service for my own use, built around pselect(2). It's single threaded by design and should never block (except, of course, on the pselect(2) call in the center of the event loop).
Then, I needed some APIs (namely getnameinfo(3) and syslog(3)) that lack an async version, so I built a little thread pool to delegate the potentially blocking stuff to different threads, thus "faking" async behavior.
This works perfectly fine on Linux and FreeBSD (didn't test any other POSIX systems), but both default to a 1:1 thread model: all threads are kernel-level threads. Now, what if the implementation would use N:M or even N:1 (PULT) threads? Is my assumption correct that, in that case, a blocking syscall would block my whole process? IOW, should I add
pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM)
for best portability to at least have kernel-level threads on any system that optionally supports them?