alex@pilosoft.com (Alex Pilosov) writes:
: [...]
: Well, it shouldn't return, but instead save the location and longjmp to
: SPI_RESUME_jmp location. On a next call, instead of a function call, it
: should longjmp back to saved location. I have to admit its more complex
: than I originally thought, but probably doable.
Implementing (what are in effect) co-routines or continuations by
setjmp/longjmp is an inherently non-portable practice. (Think about
how at all SPI_RESUME_jmp *and* the user-defined-function's saved
location could both be valid places to longjmp to at, the same time.)
At the least, you would need some assembly language code, and
heap-allocated stacks. Take a look into what user-level threading
libraries do.
If you went down this avenue, you might decide that a reasonable way
to do this is in fact to rely on first-class threads to contain the
execution context of user-defined functions. You wouldn't have the
concurrency problems normally associated with threads (since the
server would still only activate one thread at a time).
- FChE
