Re: DeviceKit and /usr
* Josselin Mouette <joss@debian.org> [090908 11:00]:
> Le mardi 08 septembre 2009 à 10:55 +0200, Bernhard R. Link a écrit :
> > Often there is something sensible: Wait till more memory is available or
> > just make the operation needing so much memory fail.
>
> If it???s an operation that specifically requires much memory, Glib
> provides g_try_*alloc functions for that. However, when allocations
> start failing for string manipulation operations, the application is
> doomed.
A lazily implemented application is doomed.
> > It's all a matter of context: for some graphical program it is usually
> > reasonable to not care and just abort. For some system daemon not
> > automatically respawned terminating because of some transient condition
> > is just a bug. (Even if Linux makes it not very easy to catch all
> > such conditions, not handling accordingly if one detects something like
> > that has no excuse but laziness).
>
> When the daemon gets in this situation, it???s very likely to be the first
> target for the OOM killer.
As I said, Linux is not especially good in out of memory handling. But
there are (still much improveable) ways to influence OOM killer and to not
make Linux give your program memory not yet available.
Not handling this means increasing the cases for failure for no better
reason but laziness.
> Note that most high-level languages are also going to simply dump an
> unhandled exception when the process gets out of memory.
Either you can catch that exception and write programs that continue
running and will work again if there is enough memory, or that language
is not suitable to write system daemons with it.
Hochachtungsvoll,
Bernhard R. Link
Reply to: