Closed gperciva closed 6 months ago
I like it, but
I don't know why you're putting everything into the .h
file as inline functions; why not just use a .c
file normally?
Needs more usage documentation, in particular "you have to call _init before forking, then _wait+_done in one process and _signal+_done in the other".
For that matter, is there any reason for _done
to be a separate function?
I submitted the .h
version because I wanted to keep the wait and signal functionality as unchanged as possible -- if that code ended up in a different .o
file, would it receive the same optimization that it did previously?
I do prefer the .c
version, so I'll put that up.
will do.
_done
could be called by signal
and wait
, but it includes close()
, which might be slow. (Especially when we switch to noeintr_close
.) So I figured that the signal & wait should be kept as fast as possible (e.g., inside timed code), while _done
could be deferred until the caller wanted it.
Don't know if you'll like this; I found it helpful for quickly adding blocking to https://github.com/Tarsnap/spiped/pull/399. And it makes
daemonize.c
easier to understand.This basically implements a semaphore with pipes (as you did in
daemonize.c
). Ideally, we'd be able to usesem_init()
etc., but that's part of the REALTIME option of POSIX, and it isn't supported by macOS. :(This version has everything in the
ipc_sync.h
file; I have another version which puts the implementation inipc_sync.c
.