[9fans] Signal (Notes) handling

[9fans] Signal (Notes) handling

[don bailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, so, in a normal multi-threaded program on any POSIX capable system
I would normally:
	1) block all signals
	2) spawn a thread whose only job is to process signals
		a) sigtimedwait() on desired signals
		b) process signals as "events" other threads can "see"
	3) other threads retrieve "events" from the signal thread at
	   their convenience

With the Notes API being substantially weaker. How does one go about
creating a proper multi-threaded application on Plan 9 with robust
Note processing akin to the above POSIX method?

Is there a way to block all notes and wait() until the desired time
to catch all Notes?

Don


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHGVXxyWX0NBMJYAcRAgIfAJ41zg+kXjkzJ5G4aE+fJsWGZfOkQgCgm5Hq
O3qfJbkE0QeZr84pTU4KqLY=
=KtjS
-----END PGP SIGNATURE-----

Re: [9fans] Signal (Notes) handling

[erik quanstrom]

notes are not compatable with threaded applications.

notes are not intended for general communications. what
is your intended application?  you may want send/recv instead.

notes aren't substantially weaker.  they solve a different
problem. from notify(2)
          When a process raises an exceptional condition such as
          dividing by zero or writing on a closed pipe, ...
signals have become a general purpose communication channel
on unix.  the condition need not be exceptional.  for example
bind's named is reloaded with SIGHUP.

on plan 9, instead of using a note, a server's control file (or files)
would be bound into the namespace.  for example, ndb/dns
is reloaded with 
	echo reload>/net/dns

the bind guys don't like signals either.  from the named(8) man page

       In routine operation, signals should not be used to control the
       nameserver; rndc should be used instead.

- erik

> Ok, so, in a normal multi-threaded program on any POSIX capable system
> I would normally:
> 	1) block all signals
> 	2) spawn a thread whose only job is to process signals
> 		a) sigtimedwait() on desired signals
> 		b) process signals as "events" other threads can "see"
> 	3) other threads retrieve "events" from the signal thread at
> 	   their convenience
> 
> With the Notes API being substantially weaker. How does one go about
> creating a proper multi-threaded application on Plan 9 with robust
> Note processing akin to the above POSIX method?
> 
> Is there a way to block all notes and wait() until the desired time
> to catch all Notes?
> 
> Don

Re: [9fans] Signal (Notes) handling

[Russ Cox]

> With the Notes API being substantially weaker. How does one go about
> creating a proper multi-threaded application on Plan 9 with robust
> Note processing akin to the above POSIX method?

easy: don't use signals for communication, like erik said.

also note that on plan 9 each "thread" (really proc) has
a distinct pid, so you *can* direct notes to individual 
threads if that's really what you want to do.

you can use semacquire and semrelease to manage a 
buffer of notes being read by the other procs.  
since semrelease is guaranteed not to block, you 
can write the note-catching proc such that it makes
no blocking calls and thus doesn't need to care that
it is getting notes fired at it at unexpected times.

but really the solution is not to use notes for these
kinds of things.  notes are for memory faults and
the like.

russ