Re: ltask - A multi tasking library for lua

[William Ahern <william@...>]

On Fri, May 01, 2015 at 09:19:36PM +0800, David Crayford wrote:
> Looks like a nice library but I'll have to give it a miss because of the 
> unchecked mallocs.
> 
>     struct queue *q = malloc(sizeof(*q));
>     // malloc never failed
>     assert(q);
> 
> In my experience malloc does fail and quite often when running on a system
> with constrained memory. I see a lot of code with unchecked mallocs on
> github and I don't like it. If it's too much effort to check return values
> why not just wrapper malloc/calloc so OOM failures set a message and exit
> cleanly? Of course, it's not just open source code that has this issue.
> I've raised many tickets for expensive enterprise software with the same
> problem.

I've been following the development of Rust recently. One of the
disconcerting issues I recently discovered is that the Rust standard
libraries exit the process on malloc failure. I think that's really
unfortunate. There are many common scenarios (e.g. network daemons) where
recovering from malloc failure is comparatively easy and very much
advisable, at least if you use the appropriate patterns from the beginning
of development. It would be ludicrous to disconnect thousands of clients
just because 1 client request triggered resource exhaustion.

I realize it's a difficult problem to solve for them. Like Lua, Rust depends
on many hidden dynamic allocations. But Rust doesn't have exceptions, and
the try! and unwrap patterns were only recently settled upon as best
practice.

Yet for a so-called systems language it's a huge negative to exit on
allocation failure. Even Lua doesn't abort the process (notwithstanding the
default panic handler). Rather, the VM remains in a consistent state.

I suppose we can't hold every project to the high standards that Lua
maintains :) Still, if a project doesn't aspire to high standards, quality
will likely be uniformly poor.