[9fans] Questions on notes

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

> I've been experimenting with how Plan 9 handles notes for processes and[color=blue]
> 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?[/color]

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);
}
}

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

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 ?
[color=blue]
> 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[/color]

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.
[color=blue]
> perhaps when doing very small io (like, say 0) furiously, the interrupts
> caused by vx don't allow the sched to happen.[/color]

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

Thanks,
Roman.

> Frankly, I was trying to see whether an external process reading[color=blue]
> 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 ?[/color]

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

> Frankly, I was trying to see whether an external process reading[color=blue]
> 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.[/color]

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?
[color=blue]
> Would this be completely impossible
> to implement using /proc/n/note ?[/color]

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.

On Nov 3, 2008, at 9:41 AM, [email]dave.l@mac.com[/email] wrote:[color=blue][color=green]
>> 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.[/color]
>
> Why?[/color]

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.
[color=blue][color=green]
>> Would this be completely impossible
>> to implement using /proc/n/note ?[/color]
>
> 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.[/color]

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.

On Tue, Nov 4, 2008 at 9:05 PM, Roman Shaposhnik <rvs@sun.com> wrote:[color=blue]
> On Nov 3, 2008, at 9:41 AM, [email]dave.l@mac.com[/email] wrote:[color=green][color=darkred]
>>>
>>> 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.[/color]
>>
>> Why?[/color]
>
> 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.[/color]

can you not just import /proc from that machine?

ron

On Nov 4, 2008, at 9:16 PM, ron minnich wrote:[color=blue]
> On Tue, Nov 4, 2008 at 9:05 PM, Roman Shaposhnik <rvs@sun.com> wrote:[color=green]
>> On Nov 3, 2008, at 9:41 AM, [email]dave.l@mac.com[/email] wrote:[color=darkred]
>>>>
>>>> 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?[/color]
>>
>> 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.[/color]
>
> can you not just import /proc from that machine?[/color]

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/