From: Russ Cox <rsc@swtch.com>
To: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
Cc: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] thread confusion
Date: Wed, 21 Sep 2005 18:44:53 -0400 [thread overview]
Message-ID: <ee9e417a05092115442e961d3c@mail.gmail.com> (raw)
In-Reply-To: <200509212234.j8LMYrG01220@zamenhof.cs.utwente.nl>
It appears that your program, at its core, it is doing this:
void
readproc(void *v)
{
int fd;
char buf[100];
fd = (int)v;
read(fd, buf, sizeof buf);
}
void
threadmain(int argc, char **argv)
{
int p[2];
pipe(p);
proccreate(readproc, (void*)p[0], 8192);
proccreate(readproc, (void*)p[1], 8192);
close(p[0]);
/* and here you expect the first readproc to be done */
close(p[1]);
/* and here the second */
}
Each read call is holding up a reference to its channel
inside the kernel, so that even though you've closed the fd
and removed the ref from the fd table, there is still a reference
to each side of the pipe in the form of the process blocked
on the read.
I've never been sure whether the implicit ref held during
the system call is good behavior, but it's hard to change.
In your case, writing 0 (or anything) makes the read
finish, releasing the last ref to the underlying pipe when
the system call finishes, and then everything cleans up
as expected. So you've found your workaround, and now
we understand why it works.
Russ
next prev parent reply other threads:[~2005-09-21 22:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-21 14:44 Fco. J. Ballesteros
2005-09-21 15:05 ` Axel Belinfante
2005-09-21 15:42 ` Russ Cox
2005-09-21 20:25 ` Axel Belinfante
2005-09-21 20:32 ` Axel Belinfante
2005-09-21 20:37 ` Russ Cox
2005-09-21 22:34 ` Axel Belinfante
2005-09-21 22:44 ` Russ Cox [this message]
2005-09-26 18:40 ` rog
2005-09-26 18:52 ` Russ Cox
2005-09-26 19:20 ` rog
2005-09-27 10:12 ` Axel Belinfante
-- strict thread matches above, loose matches on Subject: below --
2005-09-21 15:48 Fco. J. Ballesteros
2005-09-21 13:53 Fco. J. Ballesteros
2005-09-21 14:32 ` Axel Belinfante
2005-09-21 13:25 Axel Belinfante
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ee9e417a05092115442e961d3c@mail.gmail.com \
--to=rsc@swtch.com \
--cc=9fans@cse.psu.edu \
--cc=Axel.Belinfante@cs.utwente.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).