setjmp longjpm question

[nicho]

Could some knowledgable soul tell me if the following setjmp/longjmp
structure will work from a logical standpoint ? The problem is that
bar() needs to suspend processing and return control to foo() but save
it's current spot so that foo() can call bar() and have it pick up
where it left off. I'm fairly certain that bar() can longjmp to foo(),
but I'm uncertain as to whether foo() can then longjmp back to bar().
Thanks in advance for any insight.
Greg.
static jmp_buf l1;
static jmp_buf l2;

void foo(void)
{
if(setjmp(l1) == 0) bar();
-- do stuff --
longjmp(l2);

}

void bar(void)
{
-- do stuff ---
if(setjmp(l2) == 0) longjmp(l1);
-- do more stuff --
}

[Ben Pfaff]

"nicho" <gn*******@bellsouth.netwrites:

Could some knowledgable soul tell me if the following setjmp/longjmp
structure will work from a logical standpoint ? The problem is that
bar() needs to suspend processing and return control to foo() but save
it's current spot so that foo() can call bar() and have it pick up
where it left off. I'm fairly certain that bar() can longjmp to foo(),
but I'm uncertain as to whether foo() can then longjmp back to bar().

You can't portably use longjmp that way. It's likely to not work
at all on many implementations.
--
Ben Pfaff
bl*@cs.stanford.edu
http://benpfaff.org

[Eric Sosman]

nicho wrote On 02/08/07 17:10,:

Could some knowledgable soul tell me if the following setjmp/longjmp
structure will work from a logical standpoint ? The problem is that
bar() needs to suspend processing and return control to foo() but save
it's current spot so that foo() can call bar() and have it pick up
where it left off. I'm fairly certain that bar() can longjmp to foo(),
but I'm uncertain as to whether foo() can then longjmp back to bar().
Thanks in advance for any insight.
Greg.
static jmp_buf l1;
static jmp_buf l2;

void foo(void)
{
if(setjmp(l1) == 0) bar();
-- do stuff --
longjmp(l2);

}

void bar(void)
{
-- do stuff ---
if(setjmp(l2) == 0) longjmp(l1);
-- do more stuff --
}

You can only longjmp() to an "ancestor" in the call
tree, that is, to a function that is still active and has
not returned. Once a function returns, any jmp_buf it
initialized with setjmp() is no longer meaningful.

So, no: This won't work, except perhaps by pure luck.
(Don't be tempted: If you try it once and it happens to
work, there's no reason to believe it will work again.
If you survive the first round in a game of Russian
Roulette, your odds of surviving a second round do not
improve ...)

--
Er*********@sun.com

[Richard Tobin]

In article <11*********************@v45g2000cwv.googlegroups. com>,
nicho <gn*******@bellsouth.netwrote:

>Could some knowledgable soul tell me if the following setjmp/longjmp
structure will work from a logical standpoint ? The problem is that
bar() needs to suspend processing and return control to foo() but save
it's current spot so that foo() can call bar() and have it pick up
where it left off. I'm fairly certain that bar() can longjmp to foo(),
but I'm uncertain as to whether foo() can then longjmp back to bar().

As other have said, you can't portably do this, though it has worked
on some systems in the past. You'd be better off using a threads
library - most systems provide one nowadays.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[nicho]

On Feb 8, 6:48 pm, [e-mail] (Richard Tobin) wrote:

As other have said, you can't portably do this, though it has worked
on some systems in the past. You'd be better off using a threads
library - most systems provide one nowadays.

Thanks for all the replies. On reflection, I think I'll crib some
code from the state threads guys and see if I can make that work.
Again, thank you.
G.