The attachments are new prerelease versions of the files
ct.h and ctsched.c, implementing a new function ct_return().

This function is intended to be called from a thread. It
returns control directly to the scheduler through a
setjmp/longjmp mechanism. Prototype:

void ct_return( int rc );

The argument passed should be either CT_OKAY or CT_ERROR,
signifying either success or failure, respectively.

Assuming that a thread is active, the function does not
return, since it transfers control directly to the scheduler.
If you call it when no thread is active, it issues an error
message through ct_report_error() and returns.

NOTE: the ct_return function is available *only* if you compile
ctsched.c with the macro CT_RETURN #defined. Otherwise your
call to ct_return() may compile, but the linker will complain
about an unresolved external reference.

By default -- i.e. if you compile ctsched.c without #defining
the CT_RETURN macro -- both the ct_return statement and the
related setjmp() call are eliminated by conditional compilation.
That way you don't need to incur overhead for functionality
that you don't use.

Until now, the only way for a thread to return control to the
scheduler was through an ordinary return statement. In a large,
complex thread, it may be necessary to return through several
layers of function calls. In such cases it may be more
convenient, or more efficient, to use ct_return().

In particular, it may be useful to use ct_return() when you
encounter an error condition. By returning directly from a
deeply nested function you can avoid cluttering up the other
levels with a lot of tedious and error-prone error checking code.
In this respect calling ct_return() is similar to throwing an
exception in C++ or other languages.

While ct_return() may be useful, I recommend that you not use it
without carefully considering the implications of using a function
based on setjmp() and longjmp(). These functions may not work
properly in some environments. For example, in my ancient creaking
copy of Borland C/C++ 3.0, they won't work reliably in programs
that use overlays. An overlay, in this context, is Borland's way
of sort of simulating virtual memory in an operating system (MS-DOS)
that doesn't really support virtual memory.

In particular, any use of setjmp() and longjmp() is hazardous in
a C++ program. Unlike the throwing of an exception, a call to
longjmp() does not call the destructors of any objects on the stack.
Even in C, calling longjmp() may bypass certain kinds of cleanup
code in the intervening levels.

Despite all these hazards, I thought it would be worthwhile to
provide another option for those who find it useful.

I have not yet tested this new feature very thoroughly, and until
I do, I won't post it to the website. Meanwhile, you're welcome
to give it a try. Regard it as beta. Feedback and bug reports
are welcome.

Scott McKellar mck9@...
http://home.swbell.net/mck9/ct/