----- Original Message -----
From: "Christoph Reichenbach" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: zondag 5 december 1999 23:29
Subject: Re: question about code in send_selector
> Hi Rink,
Hi Christoph,
>
> > I agree with that... write a void* sci_malloc(unsigned long) function,
that
> > calls deinits, prints a message and dies whenever the allocation fails.
Great!
>
> That's roughly what the glib macros do (except for the deinitialization
> part).
Yup, I know... but I find it more readable to make a function out of this.
Just to improve readability...
>
> [implementation]
> > exit(100);
>
> Does exit code 100 mean something special I'm not aware of?
Well, I figure it'd be nice to make a fixed exit code for it...
>
>
> If we'd want to do it that way, then we could just use g_malloc, g_new,
> g_realloc, g_new0 etc. (that's what I did for src/core/* today).
> We wouldn't need to deinitialize, though; the sound server will die of
> SIGPIPE sooner or later (this has to be improved, BTW), the graphics
> system usually has minimum clean-up functions registered atexit(3), and
> memory is freed automatically. Any other cleanup stuff we might add later
> (can't think of anything, though) could be registered to be executed at
> exit, too.
Well, I figure it'd be nicer to make it with our own functions... but this
is a possibility too...
>
> Chris' concept of waiting until memory becomes available isn't going to
> help too much if we're really short on memory (the FreeSCI process is
> likely to be one of the first processes to get slaughtered by the admins),
> but it's the most technically correct solution- after all, memory shortage
> is supposed to be a recoverable problem.
Yup, I agree... it'd be neater than just die...
>
>
> llap,
> Christoph
>
Rink
>
>
