[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] Hurd servers / VFS libraries are multithreaded. # Implementation * well-known threading libraries * [[hurd/libthreads]] * [[hurd/libpthread]] # Design See [[hurd/libports]]: roughly using one thread per incoming request. This is not the best approach: it doesn't really make sense to scale the number of worker threads with the number of incoming requests, but instead they should be scaled according to the backends' characteristics. The [[hurd/Critique]] should have some more on this. [*Event-based Concurrency Control*](http://soft.vub.ac.be/~tvcutsem/talks/presentations/T37_nobackground.pdf), Tom Van Cutsem, 2009. ## IRC, freenode, #hurd, 2012-07-08 braunr: about limiting number of threads, IIRC the problem is that for some threads, completing their work means triggering some action in the server itself, and waiting for it (with, unfortunately, some lock held), which never terminates when we can't create new threads any more youpi: the number of threads should be limited, but not globally by libports pagers should throttle their writeback requests right # Alternative approaches: * * Continuation-passing style * [[microkernel/Mach]] internally [[uses continuations|microkernel/mach/continuation]], too. * [[Erlang-style_parallelism]] * [[!wikipedia Actor_model]]; also see overlap with {{$capability#wikipedia_object-capability_model}}. * [libtcr - Threaded Coroutine Library](http://oss.linbit.com/libtcr/) * --- See also: [[multiprocessing]].