From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu,  5 Dec 2013 20:51:37 -0500
To: 9fans@9fans.net
Message-ID: <a6fb96b0cdd3e20d85658349f968dbac@brasstown.quanstro.net>
In-Reply-To: <af4b600c70d2c88d71c96e6b980e9e74@felloff.net>
References: <af4b600c70d2c88d71c96e6b980e9e74@felloff.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] rio leak
Topicbox-Message-UUID: 930fa16c-ead8-11e9-9d60-3106f5b1d025

On Thu Dec  5 18:01:07 EST 2013, cinap_lenrek@felloff.net wrote:
> i just tried something out. it appears that _schedexecwait()'s
> purpose is to serve thredwaitchan():
>
>           Threadwaitchan returns a channel of pointers to Waitmsg
>           structures (see wait(2)). When an exec'ed process exits, a
>           pointer to a Waitmsg is sent to this channel.  These Waitmsg
>           structures have been allocated with malloc(2) and should be
>           freed after use.
>
> when threadwaitchan isnt used, we can rfork the execing child
> with RFNOWAIT which will make the process doing the original
> procexecl() not wait for the child.
>
> i just tried this out with rio (and abaco) and it seems to work fine.
>
> diff -r 42807d2e3f4b sys/src/libthread/main.c
> --- a/sys/src/libthread/main.c	Thu Dec 05 22:43:44 2013 +0100
> +++ b/sys/src/libthread/main.c	Fri Dec 06 23:50:34 2013 +0100
> @@ -121,9 +121,10 @@
>  int
>  _schedexec(Execargs *e)
>  {
> -	int pid;
> +	int pid, flag;
>
> -	switch(pid = rfork(RFREND|RFNOTEG|RFFDG|RFMEM|RFPROC)){
> +	flag = (_threadwaitchan == nil) ? RFNOWAIT : 0;
> +	switch(pid = rfork(RFREND|RFNOTEG|RFFDG|RFMEM|RFPROC|flag)){
>  	case 0:
>  		efork(e);
>  	default:
>
> this is saving a couple of few processes. is it worth it?

hey, that's pretty cool.  i'll bet that with this change the leaked memory
actually shows up as leaked.

- erik