mastodontech.de ist einer von vielen unabhängigen Mastodon-Servern, mit dem du dich im Fediverse beteiligen kannst.
Offen für alle (über 16) und bereitgestellt von Markus'Blog

Serverstatistik:

1,5 Tsd.
aktive Profile

#timerfd

0 Beiträge0 Beteiligte0 Beiträge heute
Felix Palmen :freebsd: :c64:<p><span class="h-card" translate="no"><a href="https://mastodon.bsd.cafe/@jan" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>jan</span></a></span> funnily, the lack of <a href="https://mastodon.bsd.cafe/tags/POSIX" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>POSIX</span></a> <a href="https://mastodon.bsd.cafe/tags/timers" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>timers</span></a> in <a href="https://mastodon.bsd.cafe/tags/OpenBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenBSD</span></a> inspired me to come up with a timer implementation supporting different backends. I was annoyed at first, but didn't regret it. The interface offered by POSIX timers is really clumsy, they can either send some signal or (even worse) launch a thread. My current code only uses them on <a href="https://mastodon.bsd.cafe/tags/illumos" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>illumos</span></a>, which offers a better signaling mechanism on an "event port". Where available, <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>kqueue</span></a> is used for timers. the next fallback is <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Linux</span></a>' <a href="https://mastodon.bsd.cafe/tags/timerfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>timerfd</span></a>. And finally, as a last resort, some manual multiplexing on top of <a href="https://mastodon.bsd.cafe/tags/setitimer" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>setitimer</span></a> (cause it's not much worse than "vanilla" POSIX timers).</p><p>tl;dr, might be an alternative to contribute code to upstream enabling them to use better platform interfaces for timers...</p>
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>I just stress-tested the current dev state of <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> on <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Linux</span></a>. The first attempt failed miserably, got a lot of errors accepting a connection. Well, this lead to another little improvement, I added another static method to my logging interface that mimics <a href="https://mastodon.bsd.cafe/tags/perror" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>perror</span></a>: Also print the description of the system errno. With that in place, I could see the issue was "too many open files". Checking <a href="https://mastodon.bsd.cafe/tags/ulimit" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ulimit</span></a> -n gave me 1024. Seriously? 🤯 On my <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>FreeBSD</span></a> machine, as a regular user, it's 226755. Ok, bumped that up to 8192 and then the stress test ran through without issues.</p><p>On a side note, this also made creating new timers (using <a href="https://mastodon.bsd.cafe/tags/timerfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>timerfd</span></a> on Linux) fail, which ultimately made swad crash. I have to redesign my timer interface so that creating a timer may explicitly fail and I can react on that, aborting whatever would need that timer.</p><p>Anyways, the same test gave somewhat acceptable results: throughput of roughly 3000 req/s, response times around 500ms. Not great, but okayish, and not directly comparable because this test ran in a <a href="https://mastodon.bsd.cafe/tags/bhyve" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>bhyve</span></a> vm and the requests had to pass the virtual networking.</p><p>One major issue is still the <a href="https://mastodon.bsd.cafe/tags/RAM" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>RAM</span></a> consumption. The test left swad with a resident set of &gt; 540 MiB. I have no idea what to do about that. 😞 The code makes heavy use of "allocated objects" (every connection object with metadata and buffers, every event handler registered, every timer, and so on), so, uses the <a href="https://mastodon.bsd.cafe/tags/heap" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>heap</span></a> a lot, but according to <a href="https://mastodon.bsd.cafe/tags/valgrind" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>valgrind</span></a>, correctly frees everything. Still the resident set just keeps growing. I guess it's the classic <a href="https://mastodon.bsd.cafe/tags/fragmentation" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>fragmentation</span></a> issue...</p>
Felix Palmen :freebsd: :c64:<p>Now that <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> 0.7 is released, it's time to prepare a new release of <a href="https://mastodon.bsd.cafe/tags/poser" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>poser</span></a>, my own lib supporting <a href="https://mastodon.bsd.cafe/tags/services" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>services</span></a> on <a href="https://mastodon.bsd.cafe/tags/POSIX" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>POSIX</span></a> systems, following a <a href="https://mastodon.bsd.cafe/tags/reactor" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>reactor</span></a> with <a href="https://mastodon.bsd.cafe/tags/threadpool" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>threadpool</span></a> design.</p><p>During development of swad, I moved poser from using strictly only POSIX APIs (with the scalability limits of e.g. <a href="https://mastodon.bsd.cafe/tags/select" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>select</span></a>) to auto-detected support for <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/eventports" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>eventports</span></a>, <a href="https://mastodon.bsd.cafe/tags/signalfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>signalfd</span></a> and <a href="https://mastodon.bsd.cafe/tags/timerfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>timerfd</span></a> (so now it could, in theory(!), "compete" with e.g. libevent). I also fixed quite some hidden bugs, and added more base functionality, like a <a href="https://mastodon.bsd.cafe/tags/dictionary" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>dictionary</span></a> using nested hashtables internally, or <a href="https://mastodon.bsd.cafe/tags/async" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>async</span></a> tasks mimicking the async/await pattern known from e.g, <a href="https://mastodon.bsd.cafe/tags/csharp" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>csharp</span></a>. I also deprecated two features, the periodic and global "service tick" (superseded by individual timers) and the "resolve hosts" property of a "connection" (superseded by a separate resolve class).</p><p>I'll have to decide on a few things, e.g. whether I'll remove the deprecated stuff immediately and bump the major version of the "posercore" lib. I guess I'll do just that. I'd also like to add all the web-specific stuff (http 1.0/1.1 server) that's currently part of the swad code as a "poserweb" lib. This would get a major version of 0, indicating a generally unstable API/ABI as of now....</p><p>And then, I'd have to decide where certain utility classes belong to. The rate limiter is probably useful for things other than web, so it should probably go to core. What about url encoding/decoding, for example? 🤔</p><p>Stay tuned, something will come here, maybe helping you to write a nice service in plain <a href="https://mastodon.bsd.cafe/tags/C" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>C</span></a> 😎:</p><p><a href="https://github.com/Zirias/poser" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">github.com/Zirias/poser</span><span class="invisible"></span></a></p>
Felix Palmen :freebsd: :c64:<p><span class="h-card" translate="no"><a href="https://chaos.social/@Toasterson" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>Toasterson</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@astade" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>astade</span></a></span> Hehe, I'm surprised it detects and uses <a href="https://mastodon.bsd.cafe/tags/signalfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>signalfd</span></a> and <a href="https://mastodon.bsd.cafe/tags/timerfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>timerfd</span></a>, which I expected to be Linux-exclusive interfaces ...</p>
Felix Palmen :freebsd: :c64:<p><span class="h-card" translate="no"><a href="https://chaos.social/@Toasterson" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>Toasterson</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@astade" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>astade</span></a></span> I'm downloading an <a href="https://mastodon.bsd.cafe/tags/OpenIndiana" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenIndiana</span></a> image right now, we will see.</p><p>For Linux, I now have support for <a href="https://mastodon.bsd.cafe/tags/epoll" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>epoll</span></a> (fd events), and additionally <a href="https://mastodon.bsd.cafe/tags/signalfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>signalfd</span></a> and <a href="https://mastodon.bsd.cafe/tags/timerfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>timerfd</span></a>. On the BSD's that have <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>kqueue</span></a>, it covers all these aspects. So, little question here: Are there any solaris / <a href="https://mastodon.bsd.cafe/tags/illumos" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>illumos</span></a> APIs specifically for signal handling and individual timers I should look into? Or should I stick to classic async handlers (signals) and setitimer (timers) on that platform, and just have a look at /dev/poll?</p>