"Eric S. Raymond" <esr(_at_)snark(_dot_)thyrsus(_dot_)com> writes:
There is a way, however -- shared-memory segments (which have the
desirable properties that they automatically vanish on a reboot and
can be made to vanish automatically when the number of processes
referencing one goes to zero). In this design, all fetchmail instances
would post their PIDs, locks, and foreground/background status to a
common shared-memory segment.
The drawback of this approach is (a) complexity, and (b) not all
Unixes support the shared-memory primitives. So -q would break on
some systems.
(c) security. Imagine root running fetchmail and it doing whatever
it's supposed to do with the shared mem. Now imagine some luser
scribbling all over that memory just prior. Ouch. I don't think
there's a safe way to do what I think you're talking about.
WHAT TO DO?
I'm tossing this out for discussion. The three basic alternatives are:
(a) leave the present locking alone in order to keep -q working everywhere.
(b) scrap client-side locking entirely -- multiple concurrent
instances would be possible, but -q would stop working.
(c) do the funky chicken with shared memory -- multiple concurrent
instances would be possible, and -q would mostly work but might
break on some platforms.
I liked Rob Funk's ideas about changing the locking semantics.
Todd