Re: [AD] Exorcising END_OF_MAIN for Allegro 5

[Peter Wang <novalazy@xxxxxxxxxx>]

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