OT: 'best' dynamic language

Igor Sysoev is at rambler-co.ru
Tue Apr 22 18:10:40 MSD 2008


On Tue, Apr 22, 2008 at 03:18:48PM +0200, Manlio Perillo wrote:

> Igor Sysoev ha scritto:
> >[...]
> >>>>>It seems that Neko as well as Lua, perl, etc do the same in memory
> >>>>>allocation failure case: exit() or nothing, i.e., segfault.
> >>>>>
> >>>>From what I can see, Lua (as Python) throws an exception in case of 
> >>>>memory allocation failure.
> >>>>
> >>>>Python uses a statically allocated object for the Memory Error 
> >>>>exception.
> >>>>
> >>>>Lua uses _longjmp/_setjmp, with integer representing error codes.
> >>>>It only calls exit if no exception handler is installed.
> >>>Well, but what can I do in exception handler ?
> >>>Destroy a whole interpreter, leaving various leaks ?
> >>>
> >>With Lua you can supply you allocator function.
> >
> >It does not resolve the problem. The interpreter internally 
> 
> The Lua interpreter?

Yes.

> >must test
> >result of EVERY function that may fail on memory allocations:
> >
> >void *
> >interpreter_function0()
> >{
> >    p = interpreter_function1();
> >    if (p == NULL) {
> >        some rollback operations
> >        return NULL;
> >    }
> >}
> >
> 
> Not sure to understand, but since memory allocation failure is signaled 
> via an exception, the code flow is quite different.
> 
> From http://www.lua.org/source/5.1/ldo.c.html#luaD_rawrunprotected:
> 
>   struct lua_longjmp lj;
>   lj.status = 0;
>   lj.previous = L->errorJmp;  /* chain new error handler */
>   L->errorJmp = &lj;
> 
>   LUAI_TRY(L, &lj,
>     (*f)(L, ud);
>   );
> 
>   L->errorJmp = lj.previous;  /* restore old error handler */
>   if (lj.status != 0) {
>      ... if memory error, destroy the interpreter
>   }
> 
> 
> and:
> #define LUAI_TRY(L,c,a) if (setjmp((c)->b) == 0) { a }

I understand the exception mechanic, this way is easy to program -
you do not need to worry about all these tests, but I'm not sure, that
it is safe way.


-- 
Igor Sysoev
http://sysoev.ru/en/





More information about the nginx mailing list