«

> Anyone, care to show how this translates into assembly after we deal
> thoroughly with this in the context of C ?

I believe that one way to look at setjmp/longjmp in C is that setjmp saves
a copy of the registers (most importantly PC and SP) and longjmp uses that
copy to jump back to the corresponding point in the program (and stack
activation).


Stefan

On Sun, 21 Oct 2007 00:55:53 +0200, "Alf P. Steinbach"
<> wrote:

> * :

> > NOTE: I am really afraid of try-catch-throw. I have never been
> > able to understand it since it does not exist in C and I cant
> > really visualize the construct in terms of C. <snip>
>
> The closest equivalent in C would be a 'longjmp'. However, a C++
> exception is more limited, in that it will only jump up the call chain,

C longjmp/setjmp also is only guaranteed to work up the stack; the
fact that _some_ implementations can work cross-stack and in
particular cross-thread is not standard nor portable.

> and it's more powerful, in that it will destroy local objects as it does
> so. Also, if you use 'longjmp' in C++ you're practically doomed (unless
> you use it to jump between co-routines with their own stacks), because
> 'longjmp' doesn't destroy local objects.
>
Actually it's Undefined Behavior; a good quality C++ implementation
CAN coordinate longjmp, and also pthreads cancellation, with
exceptions to destruct locals cleanly -- but it's not required.

- formerly david.thompson1 || achar(64) || worldnet.att.net

* David Thompson:
> On Sun, 21 Oct 2007 00:55:53 +0200, "Alf P. Steinbach"
> <> wrote:
>
>> * :
>
>>> NOTE: I am really afraid of try-catch-throw. I have never been
>>> able to understand it since it does not exist in C and I cant
>>> really visualize the construct in terms of C. <snip>
>> The closest equivalent in C would be a 'longjmp'. However, a C++
>> exception is more limited, in that it will only jump up the call chain,
>
> C longjmp/setjmp also is only guaranteed to work up the stack; the
> fact that _some_ implementations can work cross-stack and in
> particular cross-thread is not standard nor portable.

So?

But also, what on Earth do you mean by a cross-thread longjmp? I
implemented coroutines in terms of longjmp at the time that was popular,
so the concepts involved are not unfamiliar to me. Yet I fail to
envision what you could be talking about, especially as "fact". I think
perhaps you're talking about restoring the full context (registers etc)
of a moment in a thread's execution?


>> and it's more powerful, in that it will destroy local objects as it does
>> so. Also, if you use 'longjmp' in C++ you're practically doomed (unless
>> you use it to jump between co-routines with their own stacks), because
>> 'longjmp' doesn't destroy local objects.
>>
> Actually it's Undefined Behavior; a good quality C++ implementation
> CAN coordinate longjmp, and also pthreads cancellation, with
> exceptions to destruct locals cleanly -- but it's not required.

I don't know about ptheads cancellation, but other than that you're
right. Visual C++ coordinates longjmp with C++ stack unwinding. g++,
on the other hand, does not.

Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

* Alf P. Steinbach:
> * David Thompson:
>> On Sun, 21 Oct 2007 00:55:53 +0200, "Alf P. Steinbach"
>> <> wrote:
>>
>>> * :
>>
>>>> NOTE: I am really afraid of try-catch-throw. I have never been
>>>> able to understand it since it does not exist in C and I cant
>>>> really visualize the construct in terms of C. <snip>
>>> The closest equivalent in C would be a 'longjmp'. However, a C++
>>> exception is more limited, in that it will only jump up the call chain,
>>
>> C longjmp/setjmp also is only guaranteed to work up the stack; the
>> fact that _some_ implementations can work cross-stack and in
>> particular cross-thread is not standard nor portable.
>
> So?
>
> But also, what on Earth do you mean by a cross-thread longjmp? I
> implemented coroutines in terms of longjmp at the time that was popular,
> so the concepts involved are not unfamiliar to me. Yet I fail to
> envision what you could be talking about, especially as "fact". I think
> perhaps you're talking about restoring the full context (registers etc)
> of a moment in a thread's execution?
>
>
>>> and it's more powerful, in that it will destroy local objects as it
>>> does so. Also, if you use 'longjmp' in C++ you're practically doomed
>>> (unless you use it to jump between co-routines with their own
>>> stacks), because 'longjmp' doesn't destroy local objects.
>>>
>> Actually it's Undefined Behavior; a good quality C++ implementation
>> CAN coordinate longjmp, and also pthreads cancellation, with
>> exceptions to destruct locals cleanly -- but it's not required.
>
> I don't know about ptheads cancellation, but other than that you're
> right. Visual C++ coordinates longjmp with C++ stack unwinding. g++,
> on the other hand, does not.

Sorry, I didn't see the weasel-word "actually", which indicates a
contradiction.

When I wrote that you're right, that just meant that you supplied some
extra info that wasn't incorrect.

Cheers,

- Alf


--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Mon, 05 Nov 2007 06:07:25 +0100, "Alf P. Steinbach"
<> wrote:

> * David Thompson:
> > On Sun, 21 Oct 2007 00:55:53 +0200, "Alf P. Steinbach"
> > <> wrote:

> >> The closest equivalent in C would be a 'longjmp'. However, a C++
> >> exception is more limited, in that it will only jump up the call chain,
> >
> > C longjmp/setjmp also is only guaranteed to work up the stack; the
> > fact that _some_ implementations can work cross-stack and in
> > particular cross-thread is not standard nor portable.
>
> So?
>
> But also, what on Earth do you mean by a cross-thread longjmp? I
> implemented coroutines in terms of longjmp at the time that was popular,
> so the concepts involved are not unfamiliar to me. Yet I fail to
> envision what you could be talking about, especially as "fact". I think

IME 'coroutine' has been used for several slightly different concepts,
but if you mean the one of separate threads of control passing CPU
ownership often along with data anytime they choose, also known more
specifically as cooperative/nonpreemptive threading/tasking, yes. I
think you are agreeing that it did actually work, because 'restoring'
PC and SP (or equivalents) was enough; but I am pointing out it wasn't
and isn't _required_ to work that way.

> perhaps you're talking about restoring the full context (registers etc)
> of a moment in a thread's execution?
>
IME a cooperative switch itself doesn't need to save and restore other
state, as the language mechanism(s) e.g. 'call yield' handle it. Or
for cache-y things it happens automatically, or mostly automatically.

- formerly david.thompson1 || achar(64) || worldnet.att.net

* David Thompson:
> On Mon, 05 Nov 2007 06:07:25 +0100, "Alf P. Steinbach"
> <> wrote:
>
>> * David Thompson:
>>> On Sun, 21 Oct 2007 00:55:53 +0200, "Alf P. Steinbach"
>>> <> wrote:
>
>>>> The closest equivalent in C would be a 'longjmp'. However, a C++
>>>> exception is more limited, in that it will only jump up the call chain,
>>> C longjmp/setjmp also is only guaranteed to work up the stack; the
>>> fact that _some_ implementations can work cross-stack and in
>>> particular cross-thread is not standard nor portable.
>> So?
>>
>> But also, what on Earth do you mean by a cross-thread longjmp? I
>> implemented coroutines in terms of longjmp at the time that was popular,
>> so the concepts involved are not unfamiliar to me. Yet I fail to
>> envision what you could be talking about, especially as "fact". I think
>
> IME 'coroutine' has been used for several slightly different concepts,
> but if you mean the one of separate threads of control passing CPU
> ownership often along with data anytime they choose, also known more
> specifically as cooperative/nonpreemptive threading/tasking, yes. I
> think you are agreeing that it did actually work, because 'restoring'
> PC and SP (or equivalents) was enough; but I am pointing out it wasn't
> and isn't _required_ to work that way.
>
>> perhaps you're talking about restoring the full context (registers etc)
>> of a moment in a thread's execution?
>>
> IME a cooperative switch itself doesn't need to save and restore other
> state, as the language mechanism(s) e.g. 'call yield' handle it. Or
> for cache-y things it happens automatically, or mostly automatically.

Sorry, I fail to see the point, whatever it is.

But regarding definition of 'coroutine', it really doesn't map to more
than one concept.

Coroutines are treated in Knuth's TAOCPM, which locked in the
terminology (although Knuth didn't always succeed in in establishing
convention, e.g. he had to redraw his trees because he at first did them
with the root down, while the rest of the CS community chose root up,
and same for his misconception of "real time" as "reel time", he
couldn't make that stick either ); some languages, notably Modula-2,
had built-in support for coroutines; you can find some dicussion of
coroutines at <url: http://en.wikipedia.org/wiki/Coroutine>.

Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?