9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Questions on notes
@ 2008-11-03  5:48 Roman Shaposhnik
  2008-11-03 13:03 ` erik quanstrom
  0 siblings, 1 reply; 11+ messages in thread
From: Roman Shaposhnik @ 2008-11-03  5:48 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

Guys,

I've been experimenting with how Plan 9 handles notes for processes and
I must confess that I'm now confused and in need your help.

First of all, the proc(3) man page says that "A read [from /proc/n/
note] of at least ERRLEN
characters will retrieve the oldest note posted to the process and
prevent its delivery to
the process" and for some reason I have always assumed that the read
would be a blocking
one. Yet, it doesn't seem to be the case:
     term% dd -if /proc/1/note -bs 256
     0+0 record in
     0+0 records out
A visit to /sys/src/9/port/devproc.c confirms that if there are no
notes any read immediately
return with 0. At this point the whole idea of letting an external
process read notes suddenly
becomes much less appealing: the only option left to the reader is
constant polling(*). On
top of that there always seems to be a race condition between somebody
reading on /proc/n/note
and the scheduler actually delivering a note via the call to a
handler. These two things
make me the following question: what is the point of reading /proc/n/
note for anything but a
stopped/borken process?

Thanks,
Roman.

(*) Speaking of constant polling: the following hangs 9vx for good on
my system:

term% cat test.c
#include <u.h>
#include <libc.h>

void door_bell(void* dummy, char* note)
{
     print("look who's there: %s\n", note);
     noted(NCONT);
}

int main()
{
    char buf[256];
    int fd,i;

    sprint(buf, "/proc/%d/note", getpid());
    fd = open(buf, OREAD);
    notify(door_bell);
    print("starting up: %d\n", fd);
    for (;;) {
       if ((i = read(fd, buf, sizeof(buf))) < 0)
           break;
       if (i)
           print("selfserving: %s\n", buf);
    }
    return 0;
}

term%  8c test.c ; 8l test.8 ; ./8.out

EVERYTHING IS DEAD AT THIS POINT

[-- Attachment #2: Type: text/html, Size: 3026 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9fans] Questions on notes
  2008-11-03  5:48 [9fans] Questions on notes Roman Shaposhnik
@ 2008-11-03 13:03 ` erik quanstrom
  2008-11-03 16:46   ` Roman V. Shaposhnik
  0 siblings, 1 reply; 11+ messages in thread
From: erik quanstrom @ 2008-11-03 13:03 UTC (permalink / raw)
  To: 9fans

> I've been experimenting with how Plan 9 handles notes for processes and
> I must confess that I'm now confused and in need your help.
>
> First of all, the proc(3) man page says that "A read [from /proc/n/
> note] of at least ERRLEN
> characters will retrieve the oldest note posted to the process and
> prevent its delivery to
> the process" and for some reason I have always assumed that the read
> would be a blocking
> one. Yet, it doesn't seem to be the case:
>      term% dd -if /proc/1/note -bs 256
>      0+0 record in
>      0+0 records out
> A visit to /sys/src/9/port/devproc.c confirms that if there are no
> notes any read immediately
> return with 0. At this point the whole idea of letting an external
> process read notes suddenly
> becomes much less appealing: the only option left to the reader is
> constant polling(*). On
> top of that there always seems to be a race condition between somebody
> reading on /proc/n/note
> and the scheduler actually delivering a note via the call to a
> handler. These two things
> make me the following question: what is the point of reading /proc/n/
> note for anything but a
> stopped/borken process?

or a process already in a note handler?

by the way, with a small sleep in your read loop, i think 9vx
should be okay.  the attached version with a 5ms sleep generates
no noticable load on my machine

perhaps when doing very small io (like, say 0) furiously, the interrupts
caused by vx don't allow the sched to happen.

- erik

#include <u.h>
#include <libc.h>

void
handler(void *, char *s)
{
	print("handler: %s\n", s);
	noted(NCONT);
}

void
main(void)
{
	char buf[ERRMAX];
	int n, fd;

	snprint(buf, sizeof buf, "/proc/%d/note", getpid());
	notify(handler);
	fd = open(buf, OREAD);
	if(fd < 0)
		sysfatal("open notefile: %r");
	for(;;)
		switch(n = read(fd, buf, sizeof buf)){
		case -1:
			exits("");
		case 0:
			sleep(5);
			break;
		default:
			print("main: %.*s\n", n, buf);
		}
}




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9fans] Questions on notes
  2008-11-03 13:03 ` erik quanstrom
@ 2008-11-03 16:46   ` Roman V. Shaposhnik
  2008-11-03 17:05     ` Brian L. Stuart
  2008-11-03 17:41     ` dave.l
  0 siblings, 2 replies; 11+ messages in thread
From: Roman V. Shaposhnik @ 2008-11-03 16:46 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Mon, 2008-11-03 at 08:03 -0500, erik quanstrom wrote:
> > what is the point of reading /proc/n/ note for anything but a
> > stopped/borken process?
>
> or a process already in a note handler?

Could you elaborate, please? Do you mean that if the process
enters its note handler, then the sure fire way to deal with
all the pending notes would be to read a large block from
your own /proc/getpid()/note ? That actually would make sense
as far as non-blocking behavior goes. Although I still believe
that the documentation could've been clearer on that.

Frankly, I was trying to see whether an external process reading
on somebody else's /proc/n/note would make any sense. One thing
that I wanted to implement was a "note thief" process that would
constantly read on a target's /proc/n/note and handle the notes
externally using a different kind of IPC to communicate with
the target. Am I dreaming? Would this be completely impossible
to implement using /proc/n/note ?

> by the way, with a small sleep in your read loop, i think 9vx
> should be okay.  the attached version with a 5ms sleep generates
> no noticable load on my machine

Sure. But is there nothing 9vx could do internally about a situation
like this? How 9vx works is still a bit of a mystery to me, hence
the question.

> perhaps when doing very small io (like, say 0) furiously, the interrupts
> caused by vx don't allow the sched to happen.

Right. But the same scenario happening within, lets say, Qemu doesn't
lead to a catastrophe.

Thanks,
Roman.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9fans] Questions on notes
  2008-11-03 16:46   ` Roman V. Shaposhnik
@ 2008-11-03 17:05     ` Brian L. Stuart
  2008-11-03 17:41     ` dave.l
  1 sibling, 0 replies; 11+ messages in thread
From: Brian L. Stuart @ 2008-11-03 17:05 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> Frankly, I was trying to see whether an external process reading
> on somebody else's /proc/n/note would make any sense. One thing
> that I wanted to implement was a "note thief" process that would
> constantly read on a target's /proc/n/note and handle the notes
> externally using a different kind of IPC to communicate with
> the target. Am I dreaming? Would this be completely impossible
> to implement using /proc/n/note ?

If proc n needs to know about this design, then could
you just always direct the notes to the "thief?"  Or
if the thief were a little file server, could you bind
the file he listens to on top of /proc/n/note?

BLS




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9fans] Questions on notes
  2008-11-03 16:46   ` Roman V. Shaposhnik
  2008-11-03 17:05     ` Brian L. Stuart
@ 2008-11-03 17:41     ` dave.l
  2008-11-05  5:05       ` Roman Shaposhnik
  1 sibling, 1 reply; 11+ messages in thread
From: dave.l @ 2008-11-03 17:41 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> Frankly, I was trying to see whether an external process reading
> on somebody else's /proc/n/note would make any sense. One thing
> that I wanted to implement was a "note thief" process that would
> constantly read on a target's /proc/n/note and handle the notes
> externally using a different kind of IPC to communicate with
> the target.

Why?

If you want the target process to receive a different kind of IPC,
then why don't you send your different kind of IPC directly to the
process?

>  Would this be completely impossible
> to implement using /proc/n/note ?

I think so, simply because you can't "constantly read":
you need to read, process, read, ...
and while you're processing, the target process can get hit with a note.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9fans] Questions on notes
  2008-11-03 17:41     ` dave.l
@ 2008-11-05  5:05       ` Roman Shaposhnik
  2008-11-05  5:16         ` ron minnich
  0 siblings, 1 reply; 11+ messages in thread
From: Roman Shaposhnik @ 2008-11-05  5:05 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Nov 3, 2008, at 9:41 AM, dave.l@mac.com wrote:
>> Frankly, I was trying to see whether an external process reading
>> on somebody else's /proc/n/note would make any sense. One thing
>> that I wanted to implement was a "note thief" process that would
>> constantly read on a target's /proc/n/note and handle the notes
>> externally using a different kind of IPC to communicate with
>> the target.
>
> Why?

What I want is to explore a possibility of managing the processes
running
on remote machines via a proxy process (think client side of cpu(1))
running on a terminal.

>> Would this be completely impossible
>> to implement using /proc/n/note ?
>
> I think so, simply because you can't "constantly read":
> you need to read, process, read, ...
> and while you're processing, the target process can get hit with a
> note.

Yep. On a related note:  the more I think about it the more it seems
to me
that there's something I don't fully understand about the design of note
in Plan9. Hopefully, I can achieve some enlightenment here. ;-)

Thanks,
Roman.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9fans] Questions on notes
  2008-11-05  5:05       ` Roman Shaposhnik
@ 2008-11-05  5:16         ` ron minnich
  2008-11-06  5:09           ` Roman Shaposhnik
  0 siblings, 1 reply; 11+ messages in thread
From: ron minnich @ 2008-11-05  5:16 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Tue, Nov 4, 2008 at 9:05 PM, Roman Shaposhnik <rvs@sun.com> wrote:
> On Nov 3, 2008, at 9:41 AM, dave.l@mac.com wrote:
>>>
>>> Frankly, I was trying to see whether an external process reading
>>> on somebody else's /proc/n/note would make any sense. One thing
>>> that I wanted to implement was a "note thief" process that would
>>> constantly read on a target's /proc/n/note and handle the notes
>>> externally using a different kind of IPC to communicate with
>>> the target.
>>
>> Why?
>
> What I want is to explore a possibility of managing the processes running
> on remote machines via a proxy process (think client side of cpu(1))
> running on a terminal.

can you not just import /proc from that machine?

ron



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9fans] Questions on notes
  2008-11-05  5:16         ` ron minnich
@ 2008-11-06  5:09           ` Roman Shaposhnik
  0 siblings, 0 replies; 11+ messages in thread
From: Roman Shaposhnik @ 2008-11-06  5:09 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Nov 4, 2008, at 9:16 PM, ron minnich wrote:
> On Tue, Nov 4, 2008 at 9:05 PM, Roman Shaposhnik <rvs@sun.com> wrote:
>> On Nov 3, 2008, at 9:41 AM, dave.l@mac.com wrote:
>>>>
>>>> Frankly, I was trying to see whether an external process reading
>>>> on somebody else's /proc/n/note would make any sense. One thing
>>>> that I wanted to implement was a "note thief" process that would
>>>> constantly read on a target's /proc/n/note and handle the notes
>>>> externally using a different kind of IPC to communicate with
>>>> the target.
>>>
>>> Why?
>>
>> What I want is to explore a possibility of managing the processes
>> running
>> on remote machines via a proxy process (think client side of cpu(1))
>> running on a terminal.
>
> can you not just import /proc from that machine?

For a single remote process the answer is most likely "yes", but in
reality
your remote process (think a cpu-server side of cpu(1)) is almost
guaranteed
to fan itself out into a bunch of children. And then /proc/n/notepg
becomes
a real pain.

Thanks,
Roman.

P.S. It is actually a bit of a pain even for a single process if I want
things like rio(1) to be able to send signals to the remote side.
I believe that's partially the reason why cpu(1) has to establish
its covert channel for notes via registering a real catcher and
sending notes to a syntehtic filesystem. Which is, if you ask me,
a bit of a statement that notepg might actually belong to some other
place not each /proc/n/



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9fans] Questions on notes
  2008-11-03 18:48 ` Brian L. Stuart
@ 2008-11-05  2:02   ` Roman V. Shaposhnik
  0 siblings, 0 replies; 11+ messages in thread
From: Roman V. Shaposhnik @ 2008-11-05  2:02 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Mon, 2008-11-03 at 18:48 +0000, Brian L. Stuart wrote:
> > > > Frankly, I was trying to see whether an external process reading
> > > > on somebody else's /proc/n/note would make any sense. One thing
> > > > that I wanted to implement was a "note thief" process that would
> > > > constantly read on a target's /proc/n/note and handle the notes
> > > > externally using a different kind of IPC to communicate with
> > > > the target. Am I dreaming? Would this be completely impossible
> > > > to implement using /proc/n/note ?
> > >
> > > If proc n needs to know about this design, then could
> > > you just always direct the notes to the "thief?"  Or
> > > if the thief were a little file server, could you bind
> > > the file he listens to on top of /proc/n/note?
> >
> > the kernel would not notice this binding.
>
> Oh yeah--good point.  Before walk got down to it devproc
> would be in control and not care about the binding.
> I suppose you could do a sort of "note environment"
> where the server would interpose itself between apps
> and /proc sort of like how rio sits between apps
> and /dev/draw, etc.  But that's getting complicated
> and there might be something there too that I'm
> overlooking.

For the kind of thing I need it for -- the kernel sending
a note is not that big of a deal. Another process sending
a note over a /proc/weird-number/notepg is. How to
bind what I need over every potential notepg is absolutely
not clear. Although in this particular situation file-based
binding might be exactly what I need.

Thanks,
Roman.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9fans] Questions on notes
       [not found] <42d8f7e804069264141e6e4f33b8baf9@quanstro.net>
@ 2008-11-03 18:48 ` Brian L. Stuart
  2008-11-05  2:02   ` Roman V. Shaposhnik
  0 siblings, 1 reply; 11+ messages in thread
From: Brian L. Stuart @ 2008-11-03 18:48 UTC (permalink / raw)
  To: erik quanstrom, 9fans

> > > Frankly, I was trying to see whether an external process reading
> > > on somebody else's /proc/n/note would make any sense. One thing
> > > that I wanted to implement was a "note thief" process that would
> > > constantly read on a target's /proc/n/note and handle the notes
> > > externally using a different kind of IPC to communicate with
> > > the target. Am I dreaming? Would this be completely impossible
> > > to implement using /proc/n/note ?
> >
> > If proc n needs to know about this design, then could
> > you just always direct the notes to the "thief?"  Or
> > if the thief were a little file server, could you bind
> > the file he listens to on top of /proc/n/note?
>
> the kernel would not notice this binding.

Oh yeah--good point.  Before walk got down to it devproc
would be in control and not care about the binding.
I suppose you could do a sort of "note environment"
where the server would interpose itself between apps
and /proc sort of like how rio sits between apps
and /dev/draw, etc.  But that's getting complicated
and there might be something there too that I'm
overlooking.

crawling back into my cave...
BLS




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [9fans] Questions on notes
@ 2008-11-03 18:26 erik quanstrom
  0 siblings, 0 replies; 11+ messages in thread
From: erik quanstrom @ 2008-11-03 18:26 UTC (permalink / raw)
  To: blstuart, 9fans

> > Frankly, I was trying to see whether an external process reading
> > on somebody else's /proc/n/note would make any sense. One thing
> > that I wanted to implement was a "note thief" process that would
> > constantly read on a target's /proc/n/note and handle the notes
> > externally using a different kind of IPC to communicate with
> > the target. Am I dreaming? Would this be completely impossible
> > to implement using /proc/n/note ?
>
> If proc n needs to know about this design, then could
> you just always direct the notes to the "thief?"  Or
> if the thief were a little file server, could you bind
> the file he listens to on top of /proc/n/note?

the kernel would not notice this binding.

- erik



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2008-11-06  5:09 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-11-03  5:48 [9fans] Questions on notes Roman Shaposhnik
2008-11-03 13:03 ` erik quanstrom
2008-11-03 16:46   ` Roman V. Shaposhnik
2008-11-03 17:05     ` Brian L. Stuart
2008-11-03 17:41     ` dave.l
2008-11-05  5:05       ` Roman Shaposhnik
2008-11-05  5:16         ` ron minnich
2008-11-06  5:09           ` Roman Shaposhnik
2008-11-03 18:26 erik quanstrom
     [not found] <42d8f7e804069264141e6e4f33b8baf9@quanstro.net>
2008-11-03 18:48 ` Brian L. Stuart
2008-11-05  2:02   ` Roman V. Shaposhnik

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).