Discussion · bonfire.cafe

@zirias@mastodon.bsd.cafe · 5 months ago

Nice, #threadpool overhaul done. Removed two locks ( #mutex) and two condition variables, replaced by a single lock and a single #semaphore. 😎 Simplifies the overall structure a lot, and it's probably safe to assume slightly better performance in contended situations as well. And so far, #valgrind's helgrind tool doesn't find anything to complain about. 🙃

Looking at the screenshot, I should probably make #swad default to two threads per CPU and expose the setting in the configuration file. When some thread jobs are expected to block, having more threads than CPUs is probably better.

https://github.com/Zirias/poser/commit/995c27352615a65723fbd1833b2d36781cbeff4d

Process/thread details shown by top for a running swad instance, showing:

- One main thread waiting for events on kqueue
- 9 threads waiting on a semaphore, 8 of them are worker threads of a thread pool, one is a thread controlling the PAM child process
- One child process waiting on a pipe — Process/thread details shown by top for a running swad instance, showing: - One main thread waiting for events on kqueue - 9 threads waiting on a semaphore, 8 of them are worker threads of a thread pool, one is a thread controlling the PAM child process - One child process waiting on a pipe

Felix Palmen :freebsd: :c64:

@zirias@mastodon.bsd.cafe replied · 5 months ago

More #poser improvements:

* Use arc4random() if available, avoids excessive syscalls just to get high-quality random data
* Add a "resolver" to do #reverse #DNS lookups in a batch, remove the reverse lookup stuff from the connection which was often useless anyways, when a short-lived connection was deleted before resolving could finish 🙈

As a result, #swad can now reliably log requests with reverse lookups enabled 🥳

#C #coding

syslog excerpt of swad's request logging with resolving remote hosts enabled

Felix Palmen :freebsd: :c64:

@zirias@mastodon.bsd.cafe replied · 5 months ago

About the #random thingie ... I need random data in #swad to generate unpredictable #session IDs.

I previously had an implementation trying the #Linux-originating #getrandom if available, with a fallback to a stupid internal #xorshift #PRNG, which could be disabled because it's obviously NOT cryptographically secure, and WAS disabled for the generation of session IDs.

Then I learned #arc4random is available on many systems nowadays (#FreeBSD, #NetBSD, even Linux with a recent-enough glibc), so I decided to add a compile check for it and replace the whole mess with nothing but an arc4random call IF it is available.

arc4random originates from #OpenBSD and provides the only sane way to get cryptographically secure random data. It automatically and transparently (re-)seeds from OS entropy sources, but uses an internal CSPRNG most of the time (nowadays typically #ChaCha20, so it's a misnomer, but hey ...). It never fails, it never blocks. It just works. Awesome.

Felix Palmen :freebsd: :c64:

@zirias@mastodon.bsd.cafe replied · 5 months ago

I revisited that, AGAIN. Getting #random data in #poser now has yet another fallback, in case we don't have #arc4random and we also don't have #getrandom: read from /dev/random and/or /dev/urandom, "old style" 🙈. Still better to try this before resorting to a simple little #xorshift.

In the best case — arc4random found — this is still all the code of PSC_Random_bytes() 😆:

arc4random_buf(buf, count);
return count;

https://zirias.github.io/poser/api/latest/class_p_s_c___random.html

#C #coding

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances

Bonfire social · 1.0.0-rc.2.21 no JS en

Automatic federation enabled