Linux CLI tool to provide mutex locks for long running bash ops
More interesting progress trying to make #swad suitable for very busy sites!
I realized that #TLS (both with #OpenSSL and #LibreSSL) is a *major* bottleneck. With TLS enabled, I couldn't cross 3000 requests per second, with somewhat acceptable response times (most below 500ms). Disabling TLS, I could really see the impact of a #lockfree queue as opposed to one protected by a #mutex. With the mutex, up to around 8000 req/s could be reached on the same hardware. And with a lockfree design, that quickly went beyond 10k req/s, but crashed. 
So I read some scientific papers 
... and redesigned a lot (*). And now it finally seems to work. My latest test reached a throughput of almost 25k req/s, with response times below 10ms for most requests! I really didn't expect to see *this* happen. 
Maybe it could do even more, didn't try yet.
Open issue: Can I do something about TLS? There *must* be some way to make it perform at least a *bit* better...
(*) edit: Here's the design I finally used, with a much simplified "dequeue" because the queues in question are guaranteed to have only a single consumer: https://dl.acm.org/doi/10.1145/248052.248106
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
> Raspberry Pi projects?
Solved a month long mystery!
How to manage Raspberry Pi I2C device access inside ROS2/Ubuntu/Docker container **AND** outside the container in Raspberry PiOS Bookworm?
Docker invocation must map both the bus AND the mutex lock folder /var/lock/
#RaspberryPi5 #RaspberryPiOS
#I2C #Mutex #Docker #ROS2humble #Robot #GoPiGo3
@drfootleg Another tip that has been plaguing me for a month!
If you have processes inside a Docker container and other processes outside the Docker container that need mutex protection such as I2C bus or SPI bus accesses, you need to map the bus (obviously) **and** the mutex folder!
I had the sensor access working great but could not figure out why my inside and outside "mutex protected" accesses were colliding...
Think I solved why my inside Docker (ROS 2) access to I2C INA219 current sensor was colliding with my outside Docker access to the device - forgot to map the /var/lock directory so the mutex is visible from both environments!
Make Your Code Slower With Multithreading - With the performance of modern CPU cores plateauing recently, the main performance... - https://hackaday.com/2024/06/07/make-your-code-slower-with-multithreading/ #multithreading #softwarehacks #performance #profiling #spinlocks #syscall #futex #mutex #perf
#tui #daw for #jack in #rustlang
Rewrote the UI of the #midi sequencer with #ratatui for double buffering.
We're polyphonic now! Multithreaded, too - I put a #mutex between input/render/audio threads instead of message passing.
Doesn't even properly support Note Off events yet, but it does play a mean cheerful dirge. Playback cursor position still off, though.
Hooking this up to the VST host every time I restart either is bit of a faff. Gotta teach it to auto-connect the MIDI/audio ports...
