Date: Wed, 8 Jan 1997 17:42:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: wong@rogerswave.ca Cc: proff@suburbia.net, hackers@freebsd.org Subject: Re: mmap() updates...how often? Message-ID: <199701090042.RAA17405@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.91.970108183819.345A-100000@wong.rogerswave.ca> from "Ken Wong" at Jan 8, 97 06:42:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> On Wed, 8 Jan 1997 proff@suburbia.net wrote: > > > > > Why not just put them all in the same process group, and send the process > > group a SIGUSR1 when new data is ready in the mmaped region? > > > Is Signal delivery quaranteed in FreeBSD? I mean if 2 or more signals > are sent to a process at the same time. does it quene up the signals? One signal: raise condition Two signals: rais condition for first, queue second behind mask (assume it doesn't come in during race window before masking) Three signals: You are SOL. Signals are persistent conditions, not events; to use EE jargon, they are level triggered, not edge triggered. In point of fact, no signal system compliant with currently ratified POSIX standards will queue signals for delivery in FIFO (or any other, for that matter) order. Search for "POSIX +reliable +signals" on the AltaVista search site for information on POSIX standards currently in committee for event style signal queueing. Most likely you are trying to notify a process of multiple events, and you are trying to use a non-event interface (signals) to do it. Don't. Solve the problem some other way (UNIX domain sockets, pipes, message queues, counting semaphores, etc. ...there are literally dozens of alternatives). The only thing signals are barely useful for is one shot conditions (like sending HUPCL to all processes in a process group for on-to-off DCD transition on a tty line, something that can happen only once in the lifetime of the session) and for one of many events (like sending SIGCHLD when a child process dies, after which you are expected to reap as many children as you can because the signal for subsequent processes could be lost). In the second case, the processing of the signal is not as important as its mere existance: you should set a volatile flag and do your processing in your main loop -- *NOT* in the signal handler -- to close any potential race window on delivery/unmask. See the init, xdm, and inetd code for sample implementations. of "one of many". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701090042.RAA17405>