[lug] Quote of the Day

[rm at mamma.varadinet.de]

On Wed, Jan 31, 2001 at 02:57:03PM -0700, Sean Reifschneider wrote:
[...]
> Beauty is in the eye of the beholder.  To me, doing a regular variable
> access which impacts another process is "ugly".  You still need to use
> semaphores or the like to mediate access to the data, so I don't see that
> it's really any cleaner that establishing shared memory or using a
> memory mapped file...

Agreed. I think here lies one of the reasons of those problems a lot
of us find in threaded applications. Because it's (syntactically) so
easy to access data all over the program people often forget to think
of the implications of doing so. If you have to set up semaphores 
or file based loking you think twice about possible deadlocks.

> >... as long as the process doesn't share data structures with others.
> >Unfortunately, SysV IPC mechanisms don't have a 'cleanup-on-exit'. So,
> >while your OS of  choice does release resource like filehandles etc.
> 
> That's more an issue for the "master", where the processes that tend
> to die are more the helpers (which don't typicly create and destroy
> the IPC instances).

Hmm, they usually won't create instances but they might lock them
and die without removing the lock ...

> >and 'ipcrm' to do the cleanup (i recall older versions of postgresql
> >that needed manual cleanup every time a backend process died).
> 
> I haven't had to use those tools in many years, obviously postgresql
> and apache are dealing with IPC issues fairly well these days...

.. never had any problems with apache and postgresql got much better
during the last two years. I hardly ever have to use ipcrm (and if i
have to it's mostly because my frankenstein code sends some backend
into nirvana ;-)

Ralf