search for: destroy_block_coroutine

...nested co-routines (i.e. calling the same co-routine body with one call is still active, recursively). I'm not sure if having support for nested co-routines will add any value. Return This will be a regular return. Since the return value has been hijacked to point to a another block of code (destroy_block_coroutine), control will jump there instead. destroy_block_coroutine will free the linked-list of stack blocks (we have to free this, since we will won't have a reference to this list anymore), set saved_stack for this co-routine to NULL, and restore saved_sp and saved_ip. -- Sanjoy Das http://playing...

...the same co-routine body with one call > is still active, recursively). I'm not sure if having support for nested > co-routines will add any value. > > Return > > This will be a regular return. Since the return value has been hijacked > to point to a another block of code (destroy_block_coroutine), control > will jump there instead. > > destroy_block_coroutine will free the linked-list of stack blocks (we > have to free this, since we will won't have a reference to this list > anymore), set saved_stack for this co-routine to NULL, and restore > saved_sp and saved_ip. &...

...th one call >> is still active, recursively). I'm not sure if having support for nested >> co-routines will add any value. >> >> Return >> >> This will be a regular return. Since the return value has been hijacked >> to point to a another block of code (destroy_block_coroutine), control >> will jump there instead. >> >> destroy_block_coroutine will free the linked-list of stack blocks (we >> have to free this, since we will won't have a reference to this list >> anymore), set saved_stack for this co-routine to NULL, and restore >>...

...still active, recursively). I'm not sure if having support for nested >>> co-routines will add any value. >>> >>> Return >>> >>> This will be a regular return. Since the return value has been hijacked >>> to point to a another block of code (destroy_block_coroutine), control >>> will jump there instead. >>> >>> destroy_block_coroutine will free the linked-list of stack blocks (we >>> have to free this, since we will won't have a reference to this list >>> anymore), set saved_stack for this co-routine to NULL, a...

On Sun, Apr 10, 2011 at 4:16 PM, Chris Lattner <clattner at apple.com> wrote: > > On Apr 10, 2011, at 2:45 PM, Talin wrote: > > I wonder - would something like this allow for multiple stacks for a single > thread? I'm thinking of something like continuations / fibers / green > threads, which would be very handy. > > > I haven't looked at the proposal, but

On Apr 10, 2011, at 2:45 PM, Talin wrote: > I wonder - would something like this allow for multiple stacks for a single thread? I'm thinking of something like continuations / fibers / green threads, which would be very handy. I haven't looked at the proposal, but yes, this would be very useful functionality for LLVM to provide. -Chris > > On Wed, Mar 23, 2011 at 3:07 AM,