Skip to main content

Конференции

Просмотр конференции fido7.binkd:

Предыдущее Следующее

Дата: 18 Jan 2021, 17:31:00
От: Dan Cross @ 3:770/100.0
Кому: Oli
Тема: Re: Semaphore


On 18 Jan 2021 at 12:47p, Oli pondered and said...
 
 Ol> I wonder in which way signals are better in contrast to a semaphore from
 Ol> a usability / user's perspective? Yes, signals are useful, but in this
 Ol> specific case? What's wrong with a semaphore (besides that it's not hip
 Ol> in 2021)?

A couple of things, but the biggest one I can think of is fragility
in the face of system crashes.  In particular, who's responsible for
cleaning this file up?  Should `binkd` delete it as part of gracefully
exiting?  What happens if the file exists when `binkd` restarts?
That is, even if `binkd` is responsible for deleting the file, it's
possible that the system may crash in between it being created and
`binkd` cleaning it up, so `binkd` may observe the presence of the
file when it next starts up again.  Should it delete it, or refuse
to continue running?

Generally speaking, the use of a "semaphore" file (what a terrible
name) conflates the concept of issuing a control operation to some
long-running process (which is precisely what things like signals
are for) with the persistence of data provided by a filesystem.
But processes are by their nature ephemeral: they only have meaning
while running.  Once they've stopped running, that's it; there's
no mechanism to continue controlling them.  It muddies things and
unnecessarily widens the design space (forcing one to confront issues
like the above) for no apparent reason other than that's what someone
suggested.

It's clear from context that what the OP _really_ wants is just some
mechanism to signal `binkd` that it should gracefully exit once it's
done processing its current queue of work for existing connections;
implicit in this, it should _also_ deny new incoming connections and
refrain from making new outgoing connections.  In other words, it
should lame-duck and quiesce itself and then exit.  That's fine, and
seems reasonable.  The issue is that the request for enhancement didn't
say _that_, instead, it was written in terms of using this file-based
mechanism for signaling, when a perfectly good signaling mechanism
already exists and is implemented almost everywhere.

Synchronizing on files as a poor-man's IPC mechanism seems strange
when the system provides any number of existing IPC mechanisms one
can use instead.  In particular, signals were invented for
precisely this kind of signaling.

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Предыдущее Следующее

К списку сообщений
К списку конференций