101010.pl is one of the many independent Mastodon servers you can use to participate in the fediverse.
101010.pl czyli najstarszy polski serwer Mastodon. Posiadamy wpisy do 2048 znaków.

Server stats:

484
active users

#lockfree

0 posts0 participants0 posts today
Felix Palmen :freebsd: :c64:<p>Please help me spread the link to <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> 😎</p><p><a href="https://github.com/Zirias/swad" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">github.com/Zirias/swad</span><span class="invisible"></span></a></p><p>I really need some users by now, for those two reasons:</p><p>* I'm at a point where I fully covered my own needs (the reasons I started coding this), and getting some users is the only way to learn about what other people might need<br>* The complexity "exploded" after supporting so many OS-specific APIs (like <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>kqueue</span></a>, <a href="https://mastodon.bsd.cafe/tags/epoll" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>epoll</span></a>, <a href="https://mastodon.bsd.cafe/tags/eventfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>eventfd</span></a>, <a href="https://mastodon.bsd.cafe/tags/signalfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>signalfd</span></a>, <a href="https://mastodon.bsd.cafe/tags/timerfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>timerfd</span></a>, <a href="https://mastodon.bsd.cafe/tags/eventports" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>eventports</span></a>) and several <a href="https://mastodon.bsd.cafe/tags/lockfree" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>lockfree</span></a> implementations based on <a href="https://mastodon.bsd.cafe/tags/atomics" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>atomics</span></a> while still providing fallbacks for everything that *should* work on any <a href="https://mastodon.bsd.cafe/tags/POSIX" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>POSIX</span></a> systems ... I'm definitely unable at this point to think of every possible edge case and test it. If there are <a href="https://mastodon.bsd.cafe/tags/bugs" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>bugs</span></a> left (which is somewhat likely), I really need people reporting these to me</p><p>Thanks! 🙃</p>
Felix Palmen :freebsd: :c64:<p>More interesting progress trying to make <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> suitable for very busy sites!</p><p>I realized that <a href="https://mastodon.bsd.cafe/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> (both with <a href="https://mastodon.bsd.cafe/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a> and <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a>) 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 <a href="https://mastodon.bsd.cafe/tags/lockfree" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>lockfree</span></a> queue as opposed to one protected by a <a href="https://mastodon.bsd.cafe/tags/mutex" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mutex</span></a>. 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. 😆</p><p>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.</p><p>Open issue: Can I do something about TLS? There *must* be some way to make it perform at least a *bit* better...</p><p>(*) 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: <a href="https://dl.acm.org/doi/10.1145/248052.248106" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">dl.acm.org/doi/10.1145/248052.</span><span class="invisible">248106</span></a></p>