plan9fox/sys/src/lib9p/threadpostsrv.c

#include <u.h>
#include <libc.h>
#include <fcall.h>
#include <thread.h>
#include <9p.h>

int
threadpostsrv(Srv *s, char *name)
{
	if(s->forker == nil)
		s->forker = threadsrvforker;
	return postsrv(s, name);
}
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. 2021-05-01 16:37:00 +02:00			`#include <u.h>`
			`#include <libc.h>`
			`#include <fcall.h>`
			`#include <thread.h>`
			`#include <9p.h>`

lib9p: remove Srv.srvfd, make postsrv() and threadpostsrv() return the mountable file descriptor, update documentation Now that we have these new functions, we can also make them return an error instead of calling sysfatal() like postmountsrv(). Remove the confusing Srv.srvfd, as it is only temporarily used and return it from postsrv() instead. 2021-05-01 19:58:58 +02:00			`int`
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. 2021-05-01 16:37:00 +02:00			`threadpostsrv(Srv s, char name)`
			`{`
			`if(s->forker == nil)`
			`s->forker = threadsrvforker;`
lib9p: remove Srv.srvfd, make postsrv() and threadpostsrv() return the mountable file descriptor, update documentation Now that we have these new functions, we can also make them return an error instead of calling sysfatal() like postmountsrv(). Remove the confusing Srv.srvfd, as it is only temporarily used and return it from postsrv() instead. 2021-05-01 19:58:58 +02:00			`return postsrv(s, name);`
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. 2021-05-01 16:37:00 +02:00			`}`