MastodonTech.de

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:Revisiting <a href="https://mastodon.bsd.cafe/tags/async" class="mention hashtag" rel="nofollow noopener" target="_blank">#async</a> / <a href="https://mastodon.bsd.cafe/tags/await" class="mention hashtag" rel="nofollow noopener" target="_blank">#await</a> in <a href="https://mastodon.bsd.cafe/tags/POSIX" class="mention hashtag" rel="nofollow noopener" target="_blank">#POSIX</a> C, trying to "add some <a href="https://mastodon.bsd.cafe/tags/security" class="mention hashtag" rel="nofollow noopener" target="_blank">#security</a>" 🙈 Recap: Consider a classic <a href="https://mastodon.bsd.cafe/tags/reactor" class="mention hashtag" rel="nofollow noopener" target="_blank">#reactor</a>-style service in C with a <a href="https://mastodon.bsd.cafe/tags/threadpool" class="mention hashtag" rel="nofollow noopener" target="_blank">#threadpool</a> attached to run the individual request handlers. When such a handler needs to do some I/O, it'll have to wait for its completion, and doing so is kind of straight forward by just blocking the worker thread executing the job until whatever I/O was needed completes.Now, blocking a thread is never a great thing to do and I recently tooted about an interesting alternative I found: Make use of the (unfortunately deprecated) POSIX user context switching to enable releasing the worker thread while waiting. In a nutshell, you create a context with <a href="https://mastodon.bsd.cafe/tags/makecontext" class="mention hashtag" rel="nofollow noopener" target="_blank">#makecontext</a> that has its own private <a href="https://mastodon.bsd.cafe/tags/stack" class="mention hashtag" rel="nofollow noopener" target="_blank">#stack</a>, and then you can use <a href="https://mastodon.bsd.cafe/tags/swapcontext" class="mention hashtag" rel="nofollow noopener" target="_blank">#swapcontext</a> to get off the thread, and later again to get back on the thread. A minor issue is: It must be the *same* thread ... so you might have to wait until it completes something else before you can resume your job. But then, that's probably okayish, you can make sure in your job scheduling to only use worker threads with awaited tasks attached when no other thread is available.In my first implementation, I just used <a href="https://mastodon.bsd.cafe/tags/malloc" class="mention hashtag" rel="nofollow noopener" target="_blank">#malloc</a> to create a 64kiB private stack for each thread job. That's perfectly fine if you can guarantee your job will never consume more stack space, AND it won't have any vulnerabilities allowing some attacker to mess with the stack. But in practice, especially for a library offering this async/await implementation, it's nothing but a wild <a href="https://mastodon.bsd.cafe/tags/CVE" class="mention hashtag" rel="nofollow noopener" target="_blank">#CVE</a> generator.So, I now improved on that:* Allocate a much larger stack of now 2MiB. That alone makes issues at least less likely. And on a sane modern OS, we can still assume pages will only be mapped "on demand". * Only allocate the stack directly before running the thread job, and delegate allocation to some internal "stack manager" that keeps track of all allocated stacks and reuses them, only freeing them on exit. This should avoid most of the allocation overhead. * If MAP_ANON / MAP_ANONYMOUS is available, use <a href="https://mastodon.bsd.cafe/tags/mmap" class="mention hashtag" rel="nofollow noopener" target="_blank">#mmap</a> for allocating the stack. That at least gives a chance to stay away from other allocations .... * But finally, if MAP_STACK is available, use this flag! From my research, <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/OpenBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenBSD</a> and <a href="https://mastodon.bsd.cafe/tags/NetBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#NetBSD</a> will for example make sure there's at least one "guard page" below a stack mapped with this flag, so a stack overflow consistently takes the SIGSEGV emergency exit 😆. <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#Linux</a> knows this flag as well, but doesn't seem to implement such protection at this time ... 🤔 <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:Nice, <a href="https://mastodon.bsd.cafe/tags/threadpool" class="mention hashtag" rel="nofollow noopener" target="_blank">#threadpool</a> overhaul done. Removed two locks (<a href="https://mastodon.bsd.cafe/tags/mutex" class="mention hashtag" rel="nofollow noopener" target="_blank">#mutex</a>) and two condition variables, replaced by a single lock and a single <a href="https://mastodon.bsd.cafe/tags/semaphore" class="mention hashtag" rel="nofollow noopener" target="_blank">#semaphore</a>. 😎 Simplifies the overall structure a lot, and it's probably safe to assume slightly better performance in contended situations as well. And so far, <a href="https://mastodon.bsd.cafe/tags/valgrind" class="mention hashtag" rel="nofollow noopener" target="_blank">#valgrind</a>'s helgrind tool doesn't find anything to complain about. 🙃Looking at the screenshot, I should probably make <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a> 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.<a href="https://github.com/Zirias/poser/commit/995c27352615a65723fbd1833b2d36781cbeff4d" rel="nofollow noopener" translate="no" target="_blank">https://github.com/Zirias/poser/commit/995c27352615a65723fbd1833b2d36781cbeff4d</a>

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>

Dave Tabb<a href="https://mastodon.social/@khalidabuhakmeh" class="u-url mention" rel="nofollow noopener" target="_blank">@khalidabuhakmeh</a> Yeah, the business of ensuring that all the threads had finished running was a little awkward! <a href="https://mastodon.africa/tags/ThreadPool" class="mention hashtag" rel="nofollow noopener" target="_blank">#ThreadPool</a>.GetAvailableThreads <a href="https://mastodon.africa/tags/ThreadPool" class="mention hashtag" rel="nofollow noopener" target="_blank">#ThreadPool</a>.GetMaxThreads

Dave TabbToday, I multi-threaded some data analysis code in the C# language, and I DID NOT DIE! <a href="https://mastodon.africa/tags/DotNet" class="mention hashtag" rel="nofollow noopener" target="_blank">#DotNet</a> <a href="https://mastodon.africa/tags/ThreadPool" class="mention hashtag" rel="nofollow noopener" target="_blank">#ThreadPool</a>

Frühere Suchanfragen

Suchoptionen

Verwaltet von:

Serverstatistik:

#threadpool