Further to this...
Alex Hudson wrote:
> 3. potential incompatibility between GLib and XPL: for example, is
> gfree() going to work happily alongside MemFree()?
>
Jeff Steadfast, the main hacker who wrote GMime I believe, had this to
say about using it:
"The only reason I can think of that you might not want to use GMime is
that GMime uses GLib memory allocators. For daemon processes, GLib is
probably frowned upon somewhat due to the way things like g_malloc() and
g_realloc() wrappers work - if the underlying malloc()/realloc() return
NULL, then they call abort().
"So I guess it all depends on how Bongo currently handles
out-of-memory situations."
Now, at the moment, we don't have a particular policy on OOM situations,
and on the face of it calling abort() - and thereby having an agent just
quit - isn't particularly graceful.
However, and here's the thing, maybe this is the right thing to do in
general. malloc() failure is hopefully going to be very rare, and
because of that it's quite difficult to handle: we need to check it
always succeeds, and then do something sensible. But... if MemMalloc()
did an abort() on failure, we wouldn't need any of those checks and we
would always behave consistently: we'd crash on sigabrt.
Now, here's the handy thing: bongo-manager could detect that. When an
agent crashes, we could look at why, and if it's a sigabrt() we go check
the memory on the system somehow, or just assume that it's low. With one
agent down, there's a little bit of memory spare again, but we could
simply signal all the other agents to go into a 'no work' mode (e.g.,
have SMTP always return temporary errors and not accept/deliver mail).
If we're able to detect the amount of memory free, we could start the
agent up again later (when enough memory is free) and/or restart it
immediately if it looks like it had been leaking badly and just run out
of room.
I quite like this idea. It makes our code very simple and predictable,
and the only problem we have is restarting from an inconsistent state -
which is something we'd need to handle in any event.
So, thoughts on that would also be welcome :)
Thanks,
Alex.
_______________________________________________
Bongo-devel mailing list
[email protected]
https://mail.gna.org/listinfo/bongo-devel
