From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <381418fabd33474b4bdb5beb493d408c@felloff.net> Date: Sun, 20 Apr 2014 17:27:53 +0200 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] What happened on lib9p? Topicbox-Message-UUID: da1faac0-ead8-11e9-9d60-3106f5b1d025 9front adds a inferno inspired mechanism for handling requests in parallel to the 9p service loop called srvrelease()/srvacquire(). often explicitely breaking up your request handling into separate processes and handing off a request to a process seems overkill. instead, you can do a srvrelease() which will (if neccesary) spawn a new process to handle the 9p service loop while your calling process is now free to block. once you finished you do a srvacquire() to serialize with the 9p service loop again. i used this to make usb drivers multithreaded. usb devs can be slow to respond or sometimes even hang. as the filesystem is bound onto /dev, a hanging usb device would hang all walks on /dev making the system unusable with a single threaded implementation. srvrelease()/srvacquire() made these changes trivial todo. -- cinap