[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: FW: Safe an quick way to determine context in a C-function
- From: "Martijn van Buul (Ellips B.V.)" <martijn.van.buul@...>
- Date: Tue, 12 May 2009 10:33:00 +0200
From: lua-bounces@bazar2.conectiva.com.br On Behalf Of TNHarris
> On Tue, 5 May 2009 14:40:26 +0200
> "Martijn van Buul (Ellips B.V.)" <martijn.van.buul@ellips.nl> wrote:
> >
> > The problem arises if for some reason this function could fail. If
> > it's being called by Lua (from a script), the proper answer
> would be
> > to raise an error using luaL_error. However, if PushNewPoint() is
> > being called directly from the application, luaL_error will call
> > exit(), causing an immediate and rather rude termination of
> the entire
> > application. In this case, I'd much rather have PushNewPoint() to
> > return a NULL pointer, so that the calling function can gracefully
> > exit.
> >
>
> Of course the best thing is to use pcall, as Luiz said. With
> C++, I installed a panic function that throws an exception
> instead of calling exit().
Unfortunately, both solutions don't really help. First of all, I don't
have exceptions to my disposal; my target is a (partially RT) embedded
system, and the guy who wrote the OS doesn't believe in C++ exceptions,
claiming that having to support them has a potentially disastrous
effect on the latency of context switches. As a result, C++ exception
will trigger a OS panic; there's no way to recover from them. I do
have something resembling setjmp/longjmp, so that's what Lua is using.
The cpcall() solution would therefore work, but there's two issues
there:
1) The function to be cpcall()ed has only a void* argument, and all
data must go through it's own Lua stack. That defeats the purpose,
as the functions I'm trying to wrap are used to push elements on
the stack, or to retrieve data from them. Sure, I could shoe-horn
my way around it, but it would hardly be considered good design.
2) Even then, I'd have to be careful with what I do; setjmp/longjmp
in combination with C++ is a bit tricky, and can easily lead to
memory leaks.
So instead, I decided to go for the least-of-all-evil solution and
duplicate code, and have separate functions that only differ in
their error handling.