26 Sep
2015
26 Sep
'15
1:16 a.m.
Sadly I have heard a number of stories/expereiences like this. That's why
the original Posix.4 specification had a new API: asynchronous system traps
(AST) similar to what most other real time systems have had such as RSX,
VMS or VxWorks for that matter and true async I/O calls. The idea was
instead of trying to "fix" signals or read/write, put a new (optional) API
in that had the proper semantics for a real IPC (like being queued, having
priority etc...). The AST call was later removed and z queued hacked was
splitter into signals although async I/O did stay. I was sad to see AST
go. I always felt it was better to not "fix" it, but rather offer and
optional way that me the needs of people that wanted it.
FWIW: I've implemented AST a couple of times in my career into UNIX
systems. Very handy why you really want those semantics.
Clem
On Fri, Sep 25, 2015 at 6:05 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
On Mon, 21 Sep 2015, Doug McIlroy wrote:
Signal() was there first and foremost to support
SIGKILL; it did not
purport to provide a sound basis for asynchronous IPC.
Yeah, brother. In a previous life, I got burned very badly when I relied
upon signals Doing the Right Thing [tm].
I think it was dump/restor, on a BSDi box; the damned thing communicated
betwixt its child processes with signals, and I lost every backup tape
without realising it.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs