Sigmoid Social

Felix Palmen :freebsd: :c64:Please help me spread the link to <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a> 😎<a href="https://github.com/Zirias/swad" rel="nofollow noopener" translate="no" target="_blank">https://github.com/Zirias/swad</a>I really need some users by now, for those two reasons:* 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 * 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">#kqueue</a>, <a href="https://mastodon.bsd.cafe/tags/epoll" class="mention hashtag" rel="nofollow noopener" target="_blank">#epoll</a>, <a href="https://mastodon.bsd.cafe/tags/eventfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#eventfd</a>, <a href="https://mastodon.bsd.cafe/tags/signalfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#signalfd</a>, <a href="https://mastodon.bsd.cafe/tags/timerfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#timerfd</a>, <a href="https://mastodon.bsd.cafe/tags/eventports" class="mention hashtag" rel="nofollow noopener" target="_blank">#eventports</a>) and several <a href="https://mastodon.bsd.cafe/tags/lockfree" class="mention hashtag" rel="nofollow noopener" target="_blank">#lockfree</a> implementations based on <a href="https://mastodon.bsd.cafe/tags/atomics" class="mention hashtag" rel="nofollow noopener" target="_blank">#atomics</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">#POSIX</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">#bugs</a> left (which is somewhat likely), I really need people reporting these to meThanks! 🙃

Felix Palmen :freebsd: :c64:Unfortunately, I had to do a bugfix release: <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a> 0.8Although I didn't observe any obvious misbehavior on my own installation for several days, I discovered two very relevant bugs just after release of 0.7 🤦‍♂️ -- one of them (only affecting <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#kqueue</a>, for example on <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a>) even critical because it could trigger "undefined behavior".Both bugs are regressions from new (performance) improvements added, one from trying to queue as many writes as possible when sending HTTP responses, one from using kqueue to provide timers and signals.See release notes for 0.8. Don't use 0.7. Sorry 🤪 <a href="https://github.com/Zirias/swad" rel="nofollow noopener" translate="no" target="_blank">https://github.com/Zirias/swad</a>

Felix Palmen :freebsd: :c64:Now that <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</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">#poser</a>, my own lib supporting <a href="https://mastodon.bsd.cafe/tags/services" class="mention hashtag" rel="nofollow noopener" target="_blank">#services</a> on <a href="https://mastodon.bsd.cafe/tags/POSIX" class="mention hashtag" rel="nofollow noopener" target="_blank">#POSIX</a> systems, following a <a href="https://mastodon.bsd.cafe/tags/reactor" class="mention hashtag" rel="nofollow noopener" target="_blank">#reactor</a> with <a href="https://mastodon.bsd.cafe/tags/threadpool" class="mention hashtag" rel="nofollow noopener" target="_blank">#threadpool</a> design.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">#select</a>) to auto-detected support for <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#kqueue</a>, <a href="https://mastodon.bsd.cafe/tags/epoll" class="mention hashtag" rel="nofollow noopener" target="_blank">#epoll</a>, <a href="https://mastodon.bsd.cafe/tags/eventports" class="mention hashtag" rel="nofollow noopener" target="_blank">#eventports</a>, <a href="https://mastodon.bsd.cafe/tags/signalfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#signalfd</a> and <a href="https://mastodon.bsd.cafe/tags/timerfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#timerfd</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">#dictionary</a> using nested hashtables internally, or <a href="https://mastodon.bsd.cafe/tags/async" class="mention hashtag" rel="nofollow noopener" target="_blank">#async</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">#csharp</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).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....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? 🤔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">#C</a> 😎:<a href="https://github.com/Zirias/poser" rel="nofollow noopener" translate="no" target="_blank">https://github.com/Zirias/poser</a>

Felix Palmen :freebsd: :c64:The next release of <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a> will probably bring not a single new feature, but focus on improvements, especially regarding <a href="https://mastodon.bsd.cafe/tags/performance" class="mention hashtag" rel="nofollow noopener" target="_blank">#performance</a>. Support for using <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#kqueue</a> (<a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a> et al) to handle <a href="https://mastodon.bsd.cafe/tags/signals" class="mention hashtag" rel="nofollow noopener" target="_blank">#signals</a> is a part of it (which is done and works). Still unsure whether I'll also add support for <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#Linux</a>' <a href="https://mastodon.bsd.cafe/tags/signalfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#signalfd</a>. Using kqueue also as a better backend for <a href="https://mastodon.bsd.cafe/tags/timers" class="mention hashtag" rel="nofollow noopener" target="_blank">#timers</a> is on the list.Another hopefully quite relevant change is here:<a href="https://github.com/Zirias/poser/commit/798f23547295f89fa0c751f0e707c3474b5c689c" rel="nofollow noopener" translate="no" target="_blank">https://github.com/Zirias/poser/commit/798f23547295f89fa0c751f0e707c3474b5c689c</a>In short, so far my <a href="https://mastodon.bsd.cafe/tags/poser" class="mention hashtag" rel="nofollow noopener" target="_blank">#poser</a> lib was always awaiting readiness notification (from kqueue, or <a href="https://mastodon.bsd.cafe/tags/epoll" class="mention hashtag" rel="nofollow noopener" target="_blank">#epoll</a> on Linux, or select/poll for other platforms) before doing any read or write on a socket. This is the ideal approach for reads, because in the common case, a socket is NOT ready for reading ... our kernel must have received something from the remote end first. But for writes, it's not so ideal. The common case is that a socket IS ready to write (because there's space left in the kernel's send buffers). So, just try it, and only register for notifications if it ever fails, makes more sense. Avoids pointless waiting and pointless events, and e.g. with epoll, even unnecessary syscalls. 😉

Felix Palmen :freebsd: :c64:Still working on <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a>, and currently very busy with improving quality, most of the actual work done inside my <a href="https://mastodon.bsd.cafe/tags/poser" class="mention hashtag" rel="nofollow noopener" target="_blank">#poser</a> library.After finally supporting <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#kqueue</a> and <a href="https://mastodon.bsd.cafe/tags/epoll" class="mention hashtag" rel="nofollow noopener" target="_blank">#epoll</a>, I now integrated <a href="https://mastodon.bsd.cafe/tags/xxhash" class="mention hashtag" rel="nofollow noopener" target="_blank">#xxhash</a> to completely replace my previous stupid and naive hashing. I also added a more involved <a href="https://mastodon.bsd.cafe/tags/dictionary" class="mention hashtag" rel="nofollow noopener" target="_blank">#dictionary</a> class as an alternative to the already existing <a href="https://mastodon.bsd.cafe/tags/hashtable" class="mention hashtag" rel="nofollow noopener" target="_blank">#hashtable</a>. While the hashtable's size must be pre-configured and collissions are only ever resolved by storing linked lists, the new dictionary dynamically nests multiple hashtables (using different bits of a single hash value). I hope to achieve acceptable scaling while maintaining also acceptable memory overhead that way ...<a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a> already uses both container classes as appropriate.Next I'll probably revisit poser's <a href="https://mastodon.bsd.cafe/tags/threadpool" class="mention hashtag" rel="nofollow noopener" target="_blank">#threadpool</a>. I think I could replace <a href="https://mastodon.bsd.cafe/tags/pthread" class="mention hashtag" rel="nofollow noopener" target="_blank">#pthread</a> condition variables by "simple" <a href="https://mastodon.bsd.cafe/tags/semaphores" class="mention hashtag" rel="nofollow noopener" target="_blank">#semaphores</a>, which should also reduce overhead ... <a href="https://github.com/Zirias/swad" rel="nofollow noopener" translate="no" target="_blank">https://github.com/Zirias/swad</a><a href="https://mastodon.bsd.cafe/tags/c" class="mention hashtag" rel="nofollow noopener" target="_blank">#c</a> <a href="https://mastodon.bsd.cafe/tags/coding" class="mention hashtag" rel="nofollow noopener" target="_blank">#coding</a>

Felix Palmen :freebsd: :c64:Well, tried it. Works! 🥳Accepting a whole list of changes (so you can buffer them during an event loop iteration) and then even submitting them in the same call that receives events (with the changes already applied) is *indeed* a pretty cool thing with <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#kqueue</a>.<a href="https://github.com/Zirias/poser/commit/4630d6a8b87284da21097c30ea8a6ba02cc40df6" rel="nofollow noopener" translate="no" target="_blank">https://github.com/Zirias/poser/commit/4630d6a8b87284da21097c30ea8a6ba02cc40df6</a>

Felix Palmen :freebsd: :c64:First change since <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a> 0.2 will actually be a (huge?) improvement to my <a href="https://mastodon.bsd.cafe/tags/poser" class="mention hashtag" rel="nofollow noopener" target="_blank">#poser</a> lib. So far, it was hardwired to use the good old <a href="https://mastodon.bsd.cafe/tags/POSIX" class="mention hashtag" rel="nofollow noopener" target="_blank">#POSIX</a> <a href="https://mastodon.bsd.cafe/tags/select" class="mention hashtag" rel="nofollow noopener" target="_blank">#select</a> call. This is perfectly fine for handling around up to 100 (or at least less than 1000, YMMV) clients.Some <a href="https://mastodon.bsd.cafe/tags/select" class="mention hashtag" rel="nofollow noopener" target="_blank">#select</a> implementations offer defining the upper limit for checked file descriptors. Added support for that.POSIX also specifies <a href="https://mastodon.bsd.cafe/tags/poll" class="mention hashtag" rel="nofollow noopener" target="_blank">#poll</a>, which has very similar <a href="https://mastodon.bsd.cafe/tags/scalability" class="mention hashtag" rel="nofollow noopener" target="_blank">#scalability</a> issues, but slightly different. Added support for this as well.And then, I went on to add support for the <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#Linux</a>-specific <a href="https://mastodon.bsd.cafe/tags/epoll" class="mention hashtag" rel="nofollow noopener" target="_blank">#epoll</a> and <a href="https://mastodon.bsd.cafe/tags/BSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#BSD</a>-specific <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#kqueue</a> (<a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a>, <a href="https://mastodon.bsd.cafe/tags/NetBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#NetBSD</a>, <a href="https://mastodon.bsd.cafe/tags/OpenBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenBSD</a>, ...) which are both designed to *solve* any scalability issues 🥳 A little thing that slightly annoyed me about kqueue was that there's no support for temporarily changing the signal mask, so I had to do the silly dance shown in the screenshot. OTOH, it offers changing event filters and getting events in a single call, which I might try to even further optimize ... 😎<a href="https://mastodon.bsd.cafe/tags/C" class="mention hashtag" rel="nofollow noopener" target="_blank">#C</a> <a href="https://mastodon.bsd.cafe/tags/coding" class="mention hashtag" rel="nofollow noopener" target="_blank">#coding</a>

Felix Palmen :freebsd: :c64:<a href="https://mastodon.social/@toomanysecrets" class="u-url mention" rel="nofollow noopener" target="_blank">@toomanysecrets</a> It's kind of funny the talk is all about <a href="https://mastodon.bsd.cafe/tags/epoll" class="mention hashtag" rel="nofollow noopener" target="_blank">#epoll</a> although the text then correctly tells that BSD's (originally <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a> but adopted by the others as well) <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#kqueue</a> was the first async event interface without the scalability issues of <a href="https://mastodon.bsd.cafe/tags/select" class="mention hashtag" rel="nofollow noopener" target="_blank">#select</a> and <a href="https://mastodon.bsd.cafe/tags/poll" class="mention hashtag" rel="nofollow noopener" target="_blank">#poll</a>. 🙈Talking of these, I'd say the "Before epoll" paragraph is, at least partially, wrong. It just omits select/poll. Both are specified in <a href="https://mastodon.bsd.cafe/tags/POSIX" class="mention hashtag" rel="nofollow noopener" target="_blank">#POSIX</a> (and therefore available on *many* systems), and both offer the same async model, with the drawback of having scalability limitations. As a rule of thumb, they're fine for a few hundred concurrent clients, but not more.The really wasteful "forking model" (which is kind of classic Unix, really forking one process per client) predates both.It's really a shame there is no common standard for the modern, really scalable APIs. 😞 We have <a href="https://mastodon.bsd.cafe/tags/epoll" class="mention hashtag" rel="nofollow noopener" target="_blank">#epoll</a>, <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#kqueue</a>, there's "IO completion ports" in Windows, etc. I tend to still use classic <a href="https://mastodon.bsd.cafe/tags/select" class="mention hashtag" rel="nofollow noopener" target="_blank">#select</a> a lot, if more than a few hundred concurrent (!) clients is nothing you could ever expect for your software, it's still fine.

Felix Palmen :freebsd: :c64:minor new on my <a href="https://mastodon.bsd.cafe/tags/Xmoji" class="mention hashtag" rel="nofollow noopener" target="_blank">#Xmoji</a> (<a href="https://mastodon.bsd.cafe/tags/X11" class="mention hashtag" rel="nofollow noopener" target="_blank">#X11</a> <a href="https://mastodon.bsd.cafe/tags/emoji" class="mention hashtag" rel="nofollow noopener" target="_blank">#emoji</a> <a href="https://mastodon.bsd.cafe/tags/keyboad" class="mention hashtag" rel="nofollow noopener" target="_blank">#keyboad</a>): The <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#kqueue</a> backend for watching the config file now works on <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a> (as far as I can tell, hard to test every possible edge case).I also want to add <a href="https://mastodon.bsd.cafe/tags/inotify" class="mention hashtag" rel="nofollow noopener" target="_blank">#inotify</a> for <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#Linux</a>. I just realized I'll need a Linux machine to properly do that. So, installing Debian in bhyve. Joined my samba domain, mounted my <a href="https://mastodon.bsd.cafe/tags/kerberos" class="mention hashtag" rel="nofollow noopener" target="_blank">#kerberos</a>-encrypted <a href="https://mastodon.bsd.cafe/tags/NFS" class="mention hashtag" rel="nofollow noopener" target="_blank">#NFS</a> homedirs, couldn't login, no idea where to find diagnostic output with dreaded systemd ... but right now I found the solution to the problem:# ln -s /usr/bin/zsh /usr/local/bin/zsh😂🤪

Felix Palmen :freebsd: :c64:Finally some progress again with <a href="https://mastodon.bsd.cafe/tags/Xmoji" class="mention hashtag" rel="nofollow noopener" target="_blank">#Xmoji</a> (<a href="https://mastodon.bsd.cafe/tags/X11" class="mention hashtag" rel="nofollow noopener" target="_blank">#X11</a> <a href="https://mastodon.bsd.cafe/tags/emoji" class="mention hashtag" rel="nofollow noopener" target="_blank">#emoji</a> <a href="https://mastodon.bsd.cafe/tags/keyboard" class="mention hashtag" rel="nofollow noopener" target="_blank">#keyboard</a>): Added the history tab!History is persisted in a config file that should also hold other runtime config later and is watched for changes. For now, I only implemented the naive portable "watching" method periodically calling <a href="https://mastodon.bsd.cafe/tags/stat" class="mention hashtag" rel="nofollow noopener" target="_blank">#stat</a> ... backends for <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a> <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#kqueue</a> and <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#Linux</a> <a href="https://mastodon.bsd.cafe/tags/inotify" class="mention hashtag" rel="nofollow noopener" target="_blank">#inotify</a> will (hopefully!) follow 😉<a href="https://github.com/Zirias/xmoji" rel="nofollow noopener" translate="no" target="_blank">https://github.com/Zirias/xmoji</a><a href="https://mastodon.bsd.cafe/tags/xcb" class="mention hashtag" rel="nofollow noopener" target="_blank">#xcb</a> <a href="https://mastodon.bsd.cafe/tags/programming" class="mention hashtag" rel="nofollow noopener" target="_blank">#programming</a>

Felix Palmen :freebsd: :c64:General thoughts about configuration of "modern" X11 desktop apps:Next step for my <a href="https://mastodon.bsd.cafe/tags/Xmoji" class="mention hashtag" rel="nofollow noopener" target="_blank">#Xmoji</a> <a href="https://mastodon.bsd.cafe/tags/X11" class="mention hashtag" rel="nofollow noopener" target="_blank">#X11</a> <a href="https://mastodon.bsd.cafe/tags/emoji" class="mention hashtag" rel="nofollow noopener" target="_blank">#emoji</a> <a href="https://mastodon.bsd.cafe/tags/keyboard" class="mention hashtag" rel="nofollow noopener" target="_blank">#keyboard</a> will be adding runtime configuration. Sending fake key-press events has some parameters (how long to wait before restoring the keymap, which hacks/workarounds to enable for sending the events ...) that should be configurable at runtime. A history of recently used emojis should be available and persisted. There may be more things to add here later (allow multiple instances? show and use a "tray icon"?).I already have configurations for rendering and appearance aspects. For these, I use classic <a href="https://mastodon.bsd.cafe/tags/Xresources" class="mention hashtag" rel="nofollow noopener" target="_blank">#Xresources</a>. Even if they aren't that popular any more nowadays, they're IMHO the perfect place for such things: The configuration is tied to the currently running X server. They also offer a fine-grained scheme to match settings to classes and instances (e.g. individual widgets). So, learn about them and enjoy! 😄Runtime configuration is a different beast. Back in the days, you had these dialogs with the typical three buttons, "apply" made changes effective without persisting them, "ok" persisted them and "cancel" reverted anything not persisted yet. There was also often some action available to re-load the currently persisted configuration.Well, not any more. Nowadays, the predominant user experience is applying and persisting any change instantly. This is nice, but it creates an interesting issue, which most applications choose to just ignore. If either multiple instances of the same app are allowed to run for the same user on the same host, or the configuration is stored on some network share used by multiple hosts, inconsistencies are easily possible, with multiple instances of the app having a different idea about the "current" configuration and just persisting that on any change, overwriting what a different instance might have changed.I came to the conclusion that I shouldn't ignore that issue for Xmoji. At least for persisting the emoji history, it would be unacceptable.So, the obvious solution is that the configuration file must be monitored, so that any "remote" change can also be applied immediately in every running instance. The naive and portable solution for monitoring is to periodically stat() the file to check the modification timestamp. On network filesystems, that's the only thing that will work. I'll probably start with implementing just that.For local files, there are platform-specific ways to obtain notifications from the OS (or kernel), which is better (immediate notification) and more efficient. <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#Linux</a> has <a href="https://mastodon.bsd.cafe/tags/inotify" class="mention hashtag" rel="nofollow noopener" target="_blank">#inotify</a>, <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a> has <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#kqueue</a>. I'm currently exploring docs and doing a few pocs for these interfaces as well ... this might really take a while, let's see. 🙈Please comment with your thoughts about that if you have any! 😉

Recent searches

Search options

Administered by:

Server stats:

#kqueue