GameMonkey Script

GameMonkey Script Forums
It is currently Wed Aug 15, 2018 1:39 am

All times are UTC




Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Yielding From C Code
PostPosted: Wed Apr 14, 2010 5:04 pm 
Offline

Joined: Fri Jan 14, 2005 2:28 am
Posts: 439
Normally an asynchronous function would return GM_SYS_YIELD, etc for functions that are to be run asynchronously. Seems to me that you would create the microthreads within the functions that require asynchronous operation, and return the proper GM sys code, probably set up as a block() function in the general case, and within the function you'd give the thread Id to the microthread. Why would you need to register it some special way ?


Top
 Profile  
Reply with quote  
 Post subject: Re: Yielding From C Code
PostPosted: Wed Apr 14, 2010 7:06 pm 
Offline

Joined: Fri Apr 02, 2010 10:36 pm
Posts: 14
I think that approach has a couple of drawbacks:
    You need to explicitly create the microthreads in the support functions
    You need a separate scheduler to run the microthreads
    Your support routines need to handle unblocking the GM threads explicitly

I'm creating the microthreads in gmThread::PushStackFrame and running the support routine in the microthread. I only want to do this to support routines that need it, so when I register the routines they use an additional flag to say if they're asynchronous or not. With this approach, the GM thread owns the microthread, rather than the microthread having a pointer to the GM thread. This way I can use all of GameMonkey's cooperative scheduling. Support routines call MicroThread::yield, MicroThread::sleep and MicroThread::block (not yet implemented) just as GM routines do, and they behave identically. GameMonkey runs the whole show, I don't need a separate scheduler for my microthreads. My microthreads are guaranteed to run at the same time in the gameloop as the GM script does.

When a support routine returns, it's free to return GM_SYS_BLOCK or whatever just as a synchronous function would, but I don't see us using that facility often.

We have hundreds of support routines so I want to centralize the handling of the microthread creation. I think this system leaves the support routines cleaner than alternatives.

Here's the test native routine I used to test the changes:
Code:
machine->RegisterLibraryFunction("TestGmRoutine", TestGmRoutine,0,0,512); //512 is the size of the microthread stack to allocate, 0 means run without microthread

int GM_CDECL GameObject::TestGmRoutine(gmThread* a_thread)
{
        //
        //    This routine will run in a GM created microthread. You are free to MicroThread::Yield() or MicroThread::Sleep()
        //
   GM_CHECK_NUM_PARAMS(1);
   GM_CHECK_INT_PARAM(count, 0);

   for(int i=0;i<10;i++)
   {
      printf("TestGmRoutine called from script, count = %d, %d\n",count,i);
      MicroThread::Yield();    //Cause GM to Yield for a gameloop
   }
   return GM_OK;
}

and the script code
Code:
TestGmRoutine(0);
print("Done");

Neither the native code nor the script code need to worry about the asynchronous process (beyond the flag in the function registration). It works as cleanly in engine as it does in script.


Top
 Profile  
Reply with quote  
 Post subject: Re: Yielding From C Code
PostPosted: Wed Apr 14, 2010 9:08 pm 
Offline

Joined: Fri Jan 14, 2005 2:28 am
Posts: 439
Ah, I see.

Are there any portable microthread/fiber libraries out there? specifically windows + linux ? I'd like to play with some similar stuff as you are doing. It's really peaked my interest.

Honestly though, if I had a solid portable microthread library I'd be tempted to just drop GM in place of 'scripting' behaviors in C/C++ and running them in the fibers.


Top
 Profile  
Reply with quote  
 Post subject: Re: Yielding From C Code
PostPosted: Wed Apr 14, 2010 10:17 pm 
Offline

Joined: Fri Apr 02, 2010 10:36 pm
Posts: 14
DrEvil-OB wrote:
Honestly though, if I had a solid portable microthread library I'd be tempted to just drop GM in place of 'scripting' behaviors in C/C++ and running them in the fibers.

It's pretty easy to get going on other platforms, you just need to replace the one one routine. We've done it for the PS2,PS3 and XBox. The PC code has a wide open license so I'm happy to post it back here, but who knows what developer agreement I'd be breaking posting the PS3/XBox stuff, so I stripped it out.

Why I'm going to all this length is that I want to be able to mix and match the 2. I should be able to write behaviors in either system.

One of the biggest benefits of scripting to us vs. the C/C++ is that on the PS3 you have a lot more freedom in updating game scripts than with updating game code. If we can limit our updates to data, it's a lot fewer headaches. If it weren't for that, we'd probably stick with the C++.


Top
 Profile  
Reply with quote  
 Post subject: Re: Yielding From C Code
PostPosted: Thu Apr 29, 2010 7:47 pm 
Offline

Joined: Fri Apr 02, 2010 10:36 pm
Posts: 14
I posted a version of my implementation in the Resources forum. For our engine, I'm merging our microthread manager and gmmachine, so that we'll be able to run scripts or native code, or native code called from scripts all with support for the same yield, block, signal and setstate behavior.

For the sample I posted, I wanted to keep the GM changes to a minimum, so the native microthreads (those not called from GM scripts) use a different manager.


Top
 Profile  
Reply with quote  
 Post subject: Re: Yielding From C Code
PostPosted: Sat May 01, 2010 3:58 am 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 703
That looks very cool YourUncleBob! Thanks for sharing.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group