gvanderk@navier.UVic.CA (Geoff  Vanderkooy) writes:

>Although I have not tried to use setjmp() or longjmp(), I think I can
>explain your problem.  Class instances pass their data by including an
>implicit first argument, the _this_ pointer.  I don't believe setjmp() or
>longjmp() will include the _this_pointer - so the data is effectively lost.

If this is the problem, can you get around calling these routines from
w/in a member function entirely?  Just have your member functions call
a non-member function which then calls longjmp.  If the 'this' pointer
must be part of this call, pass it explicitly.

I ran into a problem like this when using Sun's LWP (Light Weight Process)
thread library under Solaris 1.  Doing the above worked very well for me.

Hope it helps,

--Derek Jones
  dtj@rincon.primenet.com


--
-------------------------------------------------------------------------------
Derek Jones
dtj@primenet.com
-------------------------------------------------------------------------------

In article <3j0n7b$q46@newsstand.cit.cornell.edu>,
pbenton@sunlab.cit.cornell.edu (Phillips Benton) wrote:
>    I'm trying to write a multitasking game in C++ using setjmp and longjmp.
> Unfortunately when I longjmp() to a setjmp()'ed address *in a member function*,
> I seem to lose all of the object's data.  The pointer wanders off to who-knows-where.
> Has anybody else tryed using setjmp() and longjmp() with C++?  Help!
>            -Alex
>
>

As you've already seen, you can't multi-task with longjmp() - in effect,
longjmp() discards its context and setjmp() can only retain its context until
the first time it is unwound from the stack (which longjmp() does!).

Your *best* solution is definitely to use threads, as suggested elsewhere, but
I presume that you are running under DOS, so this is difficult.  You *may* be
interested in using COROUTINES, which are effectively a cheap form of
cooperative multithreading just as you were trying to do (instead, you use
routines callco() and cowait() to transfer between "threads").
    If you are interested in coroutines, mail me.  They are are straightforward
enough to implement, but the implementation is very environment dependent.

P.S.  Apologies for contaminating the comp.std.c++ space with irrelevance.

In article <3j0n7b$q46@newsstand.cit.cornell.edu> pbenton@sunlab.cit.cornell.edu (Phillips Benton) writes:
>   I'm trying to write a multitasking game in C++ using setjmp and longjmp.
>Unfortunately when I longjmp() to a setjmp()'ed address *in a member function*,
>I seem to lose all of the object's data.  The pointer wanders off to who-knows-where.
>Has anybody else tryed using setjmp() and longjmp() with C++?  Help!
>           -Alex

Although I have not tried to use setjmp() or longjmp(), I think I can
explain your problem.  Class instances pass their data by including an
implicit first argument, the _this_ pointer.  I don't believe setjmp() or
longjmp() will include the _this_pointer - so the data is effectively lost.

I think there are probably better ways to accomplish what you desire
(unfortunately, I don't know what they are - a task stack maybe?).

Good luck.
  Geoff

jmackraz@netcom.com (Jim Mackraz) writes:

>In article <3j2eeg$ofu@wcap.centerline.com>,
>David Chase <chase@michaelcenterline.com> wrote:
>>pbenton@sunlab.cit.cornell.edu (Phillips Benton) writes:
>>>    I'm trying to write a multitasking game in C++ using setjmp and longjmp.
>>> Unfortunately when I longjmp() to a setjmp()'ed address *in a member function*,
>>> I seem to lose all of the object's data.  The pointer wanders off to who-knows-where.
>>> Has anybody else tryed using setjmp() and longjmp() with C++?  Help!
>>
>>I don't think there's any standard anywhere that guarantees
>>that setjmp and longjmp will work in the way that you wish.
>>They have, accidentally, at some points in the past, but it
>>is purely an implementation-dependent accident.  It varies from
>>compiler to compiler, too.  You could well be getting a bogus
>>"this" pointer.

>What part of the program's "state" is not preserved by setjmp/longjmp?
>Same code, same stack, same registers...?  Where do they store the 'this'
>pointer that might be bogus?  In Jah Global?

>  Jim

Chances are your are not in the same stack frame when you call longjmp.
In order for longjmp to work it must be called in the same stack frame as the
setjmp was called.  Otherwise the address for longjmp to jump to is no longer
on the stack.  In other words, the function that called the setjmp must
still be active when the longjmp is called.


Gordon Fleming

--
* Gordon Fleming                     *
* gfleming@cml.com                   *
* a270flem@ugsparc0.eecg.toronto.edu *
* a270flem@cdf.toronto.edu           *

>    I'm trying to write a multitasking game in C++ using setjmp and longjmp.
> Unfortunately when I longjmp() to a setjmp()'ed address *in a member function*,
> I seem to lose all of the object's data.  The pointer wanders off to who-knows-where.
> Has anybody else tryed using setjmp() and longjmp() with C++?  Help!
>            -Alex
>
>
Alex, I'm pleased, I'm Alex 2oo. I've tried 2 use some other techniques
to get rid of my data by insulting this pointer in a way u did. in all
cases only Turbo Debugger could rescue me. Send me your code fragment,
I'd try 2 find the way how 2 stop losing your data.

ARCHER.

P.S. Welcome on MONO (mono.city.ac.uk)!

In article <1995Mar5.174353.28675@sol.UVic.CA>, gvanderk@navier.UVic.CA
says...
>
>In article <3j0n7b$q46@newsstand.cit.cornell.edu>
pbenton@sunlab.cit.cornell.edu (Phillips Benton) writes:
>>   I'm trying to write a multitasking game in C++ using setjmp and
longjmp.
>>Unfortunately when I longjmp() to a setjmp()'ed address *in a member
function*,
>>I seem to lose all of the object's data.  The pointer wanders off to
who-knows-where.
>>Has anybody else tryed using setjmp() and longjmp() with C++?  Help!
>>           -Alex
>
>Although I have not tried to use setjmp() or longjmp(), I think I can
>explain your problem.  Class instances pass their data by including an
>implicit first argument, the _this_ pointer.  I don't believe setjmp() or
>longjmp() will include the _this_pointer - so the data is effectively
lost.
>
>I think there are probably better ways to accomplish what you desire
>(unfortunately, I don't know what they are - a task stack maybe?).
>
>Good luck.
>  Geoff
>
>

I have an object oriented multitasking kernel (OORTK2) written in C++ with
a resolution down to 1mS. OORTK was originally created for Turbo Pascal
5.5 and above, but a C++ version is being tried by several of my students.

I can make a copy of OORTK2.OBJ and OORTK2.H available via FTP with some
brief notes if there is a demand.

John Scott
North East Wales Institute

In article <jmackrazD4sIK7.J31@netcom.com>,
Jim Mackraz <jmackraz@netcom.com> wrote:
>In article <3j2eeg$ofu@wcap.centerline.com>,
>David Chase <chase@michaelcenterline.com> wrote:
>>pbenton@sunlab.cit.cornell.edu (Phillips Benton) writes:
>>>    I'm trying to write a multitasking game in C++ using setjmp and longjmp.
>>> Unfortunately when I longjmp() to a setjmp()'ed address *in a member function*,
>>> I seem to lose all of the object's data.  The pointer wanders off to who-knows-where.
>>> Has anybody else tryed using setjmp() and longjmp() with C++?  Help!
>>
>>I don't think there's any standard anywhere that guarantees
>>that setjmp and longjmp will work in the way that you wish.
>>They have, accidentally, at some points in the past, but it
>>is purely an implementation-dependent accident.  It varies from
>>compiler to compiler, too.  You could well be getting a bogus
>>"this" pointer.
>
>What part of the program's "state" is not preserved by setjmp/longjmp?
>Same code, same stack, same registers...?  Where do they store the 'this'
>pointer that might be bogus?  In Jah Global?

Setjmp and longjmp only work when setjmp is in a stack frame *before* the
longjmp is called, at which point the stack is rolled back to the setjmp.

You can't implement multitasking with *just* setjmp and longjmp.  You need
to allocate separate stacks for each task and this is machine dependent.
Setjmp/longjmp in C++ is rather dangerous imho and are now outdated by
exception handling.  I bet the original poster tried to longjmp forward
after having longjmp'd back.  From the man page:
 'Absolute chaos is guaranteed.'

For DOS, try looking for the c++ task package that appeared in Dr. Dobb's
Journal a couple of years ago.  For Unix systems, look for a POSIX threads
package (ftp sipb.mit.edu /pub/pthreads is one).

. . . Zun.

>>pbenton@sunlab.cit.cornell.edu (Phillips Benton) writes:
>>>    I'm trying to write a multitasking game in C++ using setjmp and longjmp.
>>> Unfortunately when I longjmp() to a setjmp()'ed address *in a member function*,
>>> I seem to lose all of the object's data.  The pointer wanders off to who-knows-where.
>>> Has anybody else tryed using setjmp() and longjmp() with C++?  Help!

>In article <3j2eeg$ofu@wcap.centerline.com>,
>David Chase <chase@centerline.com> wrote:
>>I don't think there's any standard anywhere that guarantees
>>that setjmp and longjmp will work in the way that you wish.
>>They have, accidentally, at some points in the past, but it
>>is purely an implementation-dependent accident.  It varies from
>>compiler to compiler, too.  You could well be getting a bogus
>>"this" pointer.

jmackraz@netcom.com (Jim Mackraz) writes:
> What part of the program's "state" is not preserved by setjmp/longjmp?
> Same code, same stack, same registers...?  Where do they store the 'this'
> pointer that might be bogus?  In Jah Global?

State?  Who said anything about state?  In the worst case, setjmp
merely specifies a PC and frame pointer -- any local variables
allocated to registers lose their values upon execution of a longjmp.
(It is a fortunate accident that on Sparc, restoring the PC and SP/FP
is usually sufficient to restore all your locals in registers to
their most recent values, assuming that the C optimizer is
sufficiently conservative about shuffling different variables in and
out of registers in the presence of setjmp, which it usually is.)

Or, if you'd like a different worst case, suppose we arrange that
longjmp restores all the variables to their correct, most recent,
values in the frame which called setjmp, and it does this by crawling
up the stack and undoing register save operations.  Works *great* for
the specified uses of setjmp/longjmp, but if you're using it for
threads, you'll crawl all the way to the bottom of stack without
finding your target frame.  Oops.

So, basically, you should never read more into a standard than is
actually written there.  Just because you can imagine a particular
implementation of something, doesn't mean it is actually implemented
that way (*). And, if you really want something to be implemented in
a particular tricky way, do it yourself, in assembly language, or bug
your vendor for a separate interface that provides the (DEFINED)
behavior that you need.

I realize that this doesn't answer your question about "where did
they put the 'this' pointer", but I claim that is irrelevant, because
the implementors were not required to restore it to a sensible value.
Even if they had an answer that worked today, they might change the
answer tomorrow.

(*) I worked as a Sparc compiler/optimizer back-end designer/hacker
for 3 years.  There are twisted ways to implement many different
things, and if the twisted way is faster, there's a good chance that
you'll see it someday.

yours,

David Chase, speaking for myself

   I'm trying to write a multitasking game in C++ using setjmp and longjmp.
Unfortunately when I longjmp() to a setjmp()'ed address *in a member function*,
I seem to lose all of the object's data.  The pointer wanders off to who-knows-where.
Has anybody else tryed using setjmp() and longjmp() with C++?  Help!
           -Alex

pbenton@sunlab.cit.cornell.edu (Phillips Benton) writes:
>    I'm trying to write a multitasking game in C++ using setjmp and longjmp.
> Unfortunately when I longjmp() to a setjmp()'ed address *in a member function*,
> I seem to lose all of the object's data.  The pointer wanders off to who-knows-where.
> Has anybody else tryed using setjmp() and longjmp() with C++?  Help!

I don't think there's any standard anywhere that guarantees
that setjmp and longjmp will work in the way that you wish.
They have, accidentally, at some points in the past, but it
is purely an implementation-dependent accident.  It varies from
compiler to compiler, too.  You could well be getting a bogus
"this" pointer.

What you should do instead is use POSIX threads.

If that answer is not good enough, and your platform of choice
is a Sparc running either SunOS or Solaris, send me mail and
I'll send you a few scraps of code that implement very minimal
coroutines for either OS.

yours,

David Chase

Ugh.  Just now I notice "BC++", so my offer of help with
Suns is irrelevant.  Also note the correct return address,
not that you'll be needing it.  The comments about non-
standard use of setjmp and longjmp still stand, but someone
somewhere should know the assembly language that you need.
Or, pound on your language vendor to get with the program
(or find another language vendor).

David

In article <3j2eeg$ofu@wcap.centerline.com>,
David Chase <chase@michaelcenterline.com> wrote:
>pbenton@sunlab.cit.cornell.edu (Phillips Benton) writes:
>>    I'm trying to write a multitasking game in C++ using setjmp and longjmp.
>> Unfortunately when I longjmp() to a setjmp()'ed address *in a member function*,
>> I seem to lose all of the object's data.  The pointer wanders off to who-knows-where.
>> Has anybody else tryed using setjmp() and longjmp() with C++?  Help!
>
>I don't think there's any standard anywhere that guarantees
>that setjmp and longjmp will work in the way that you wish.
>They have, accidentally, at some points in the past, but it
>is purely an implementation-dependent accident.  It varies from
>compiler to compiler, too.  You could well be getting a bogus
>"this" pointer.

What part of the program's "state" is not preserved by setjmp/longjmp?
Same code, same stack, same registers...?  Where do they store the 'this'
pointer that might be bogus?  In Jah Global?

  Jim