> > I intentionally use *unnamed* semaphores to avoid these problems --
> > even if the semaphores didn't go away (as Magus pointed out, if all
> > processes can exit gracefully, this won't happen), we won't worry
> > about them -- Creating semahpores will still succeed
> because there is
> > no existent same named semaphores will bother it.
>
> Except that eventually you run the kernel out of resources.
> We were forced to confront that point very early when dealing
> with the SysV API, because of the remarkably low resource
> limits it traditionally has, but long-term resource leaks are
> never a good idea in any software.
Most definitly.
Windows will easily handle thousands, or tends of thousands, of
semaphores, but leaking them is never acceptable behaviour. But the
bottom line is that the objects are automatiaclly destroyed when all
processes holding open handles to them exit - which IIRC is not the case
with SysV ones. And if we leak *processes* that don't exit, that's a
much bigger problem.
> Or are you designing this according to the widespread view
> that Windows system uptimes are measured in small numbers of
> days anyway?
Widespread misunderstanding, I'd say.
Today, a properly configured windows db server shuold normally have
uptimes well exceeding half a year, often over a year. No, that's not as
good as a properly configured unix box, but it's certainly not few
enough days not to care about leakage. So it's definitly not something
we should even consider as an excuse.
(note that "properly configured" includes "properly firewalled so you
don't need to apply the monthly set of patches every time")
//Magnus