ref: f6509078ed9d03b71c945b19cdda5c882cb1e78d
parent: 013b4983140cc2fbb7df9e3647e2e7c5d575a9dd
author: cinap_lenrek <cinap_lenrek@felloff.net>
date: Sat May 1 12:37:00 EDT 2021
lib9p: expose Srv.forker handler and srvforker(), threadsrvforker() and threadsrv() functions To use srvrease()/srvaquire() we need to have a way to spawn new processes to handle the service loop. This functionality was provided by the internal _forker() function which was eigther rfork or libthread based implementation depending on if postmountsrv() or threadpostmountsrv() where called. For servers who want to use srv() directly, _forker would not be initialized so srvrelease() could not be used. To untangle this, we get rid of the global _forker handler and put the handler in the Srv structure. Which will get initialized (when nil) to eigther srvforker() or threadsrvforker() depending on if the thread or non-thread entry points where used. For symmetry, we provde new threadsrv() and threadpostsrv() functions which handle the default initialization of Srv.forker. This also allows a user to provide his own forker function, maybe to conserve stack space. To avoid dead code, we put each of these function in their own object file. Note, this also allows a user to define its own srvforker() symbol.