[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT problems
- From: "Mark Meijer" <meijer78@...>
- Date: Tue, 29 Jan 2008 20:08:14 +0100
On 29/01/2008, Mike Pall <firstname.lastname@example.org> wrote:
> This may sound strange, coming from me, but LuaJIT is just a tool
> with specific strengths and specific weaknesses (as you've
> discovered). Only use a tool, if it fits the problem at hand.
Sure. LuaJIT is entirely optional in this case. I just thought I'd
give it a whirl and see how it works. And if it fits, then of course I
don't mind the speed benefit ;) But I get your point.
> GUI libraries are known for their (sometimes) excessive stack
> usage. I have no first-hand experience with wxLua, though. You
> could try doing all GUI work from coroutines created with a
> larger C stack (see the LuaJIT docs for coroutine.create() and
I'll check that out. At this point, all GUI stuff (for what it's worth
at the moment) is done strictly from the main thread. I may or may not
keep it that way, haven't decided yet. But I assume that the stack
size set with those compiler/linker flags, applies to the main thread
as well. So then that would be the reason for moving GUI stuff to a
coroutine with a larger stack, right?
> Fibers are the only (reasonable) way to do this under Windows.
> There's some undocumented stuff going on behind the Windows Fiber
> API (like switching SEH handlers). It varies depending on the
> Windows version, too. I've tried to create C stacks "by hand" for
> Windows, but this experiment failed miserably.
Then just out of curiosity, how was that different from the Linux
implementation? Or, what does Linux provide for it that won't work in
Windows? (unless it's too much to explain... I'm taking your word for
it, I just honestly don't know :) ).