Re: [AD] Exorcising END_OF_MAIN for Allegro 5

["Peter Hull" <peterhull90@xxxxxxxxxx>]

This seems to work, not sure if it's right though.

Pete


On Mon, Jul 14, 2008 at 7:33 PM, Peter Hull <peterhull90@xxxxxxxxxx> wrote:
> Just one snag-ette - no ucontext on OS X! (it may be in 10.5, it isn't
> in 10.4). Actually ucontext is defined but no make/swap/getcontext.
> This is despite it being a BSD function.
>
> More thought required!
>
> Pete
>
>
> On Mon, Jul 14, 2008 at 1:06 PM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
>> No, that should work.  When thread_func resumes into main, it will be
>> running on main's original stack.  hijacker runs on the stack st2.
>> Which leaves the stack allocated by pthread_create() wasted...
>>
>> Peter
>>
>> On 2008-07-14, Peter Hull <peterhull90@xxxxxxxxxx> wrote:
>>> I'll try it. I'm not a ucontext expert either!  I think you'd need to
>>> copy main's stack into the new thread first (is this possible?)
>>> otherwise something like the following would fail.
>>> int main()
>>> {
>>>  int myvar = 99;
>>>  al_init();
>>>  do_something_with(my_var); // crash because it's gone..!
>>>  return 1;
>>> }
>>>
>>> Pete
>>>
>>> On 7/14/08, Peter Wang <novalazy@xxxxxxxxxx> wrote:
>>> > On 2008-07-14, Peter Hull <peterhull90@xxxxxxxxxx> wrote:
>>> > > On 7/14/08, Peter Wang <novalazy@xxxxxxxxxx> wrote:
>>> > > > The problem used to be that one of the Mac libraries needed to take over
>>> > > > the main thread, so we had to relegate the user's code to another
>>> > > > thread.  I hope it has changed.
>>> > > Right, the OS will only deliver events to the main thread but in
>>> > > Allegro 4 there was nowhere in the user's code where we could reliably
>>> > > receive and dispatch the events. Magic main is used to run the user's
>>> > > main() in a second thread. A5 uses the same design at the moment. We
>>> > > could get around this if we require the user to call al_wait_for_event
>>> > > regularly (which I think is not the current case) or figure out some
>>> > > way to return from al_init but in a different thread (longjmp,
>>> > > ucontext or similar)
>>> >
>>> > This is an interesting idea!
>>> >
>>> > Can you do something with the attached code?  This is the first time I've used
>>> > ucontext so it's probably not 100% correct.  I get this output:
>>> >
>>> >    main entered in [b7e4e6c0]
>>> >    thread_func in [b7e4db90]
>>> >    main resumed in [b7e4db90]
>>> >    hijacker in [b7e4e6c0]
>>> >
>>> > Peter
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> --
>> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>>
>

Attachment: hijack2.c
Description: Binary data