* [9fans] rio leak
@ 2013-12-05 3:22 erik quanstrom
2013-12-05 22:59 ` cinap_lenrek
0 siblings, 1 reply; 3+ messages in thread
From: erik quanstrom @ 2013-12-05 3:22 UTC (permalink / raw)
To: 9fans
has anyone seen rio leaking gobs of memory?
quanstro 469813 0:00 0:00 43008K Await rio
leak says all the memory is allocated, and almost of all of it
is allocated @ the text buffer rellocation. it also looks like
there are more rio processes than windows. one funny thing
is a lot of processes are stuck in _schedexecwait(). funny....
- erik
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [9fans] rio leak
2013-12-05 3:22 [9fans] rio leak erik quanstrom
@ 2013-12-05 22:59 ` cinap_lenrek
2013-12-06 1:51 ` erik quanstrom
0 siblings, 1 reply; 3+ messages in thread
From: cinap_lenrek @ 2013-12-05 22:59 UTC (permalink / raw)
To: 9fans
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?
--
cinap
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [9fans] rio leak
2013-12-05 22:59 ` cinap_lenrek
@ 2013-12-06 1:51 ` erik quanstrom
0 siblings, 0 replies; 3+ messages in thread
From: erik quanstrom @ 2013-12-06 1:51 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-12-06 1:51 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-05 3:22 [9fans] rio leak erik quanstrom
2013-12-05 22:59 ` cinap_lenrek
2013-12-06 1:51 ` erik quanstrom
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).