4

Hi I'm need to jump from a place to another...

But I would like to know which is better to use, setjmp or ucontext, things like:

  • Are setjmp and ucontext portable?
  • My code is thread safe using these library?
  • Why use one instead another?
  • Which is fast and secure?
  • ...(Someone please, can answer future question that I forgot to put here?)

Please give a little more information that I'm asking for, like examples or some docs...

I had searching on the web, but I only got exception handling in C like example of setjmp, and I got nothing about ucontex.h, I got that it was used for multitask, what's the difference of it and pthread?

Thanks a lot.

drigoSkalWalker
  • 2,742
  • 9
  • 32
  • 45

3 Answers3

5

setjmp is portable (ISO C89 and C99) and ucontext (obsolescent in SUSv3 and removed from SUSv4/POSIX 2008) is not. However ucontext was considerably more powerful in specification. In practice, if you used nasty hacks with setjmp/longjmp and signal handlers and alternate signal handling stacks, you could make these just about as powerful as ucontext, but they were not "portable".

Neither should be used for multithreading. For that purpose POSIX threads (pthread functions). I have several reasons for saying this:

  • If you're writing threaded code, you might as well make it actually run concurrently. We're hitting the speed limits of non-parallel computing and future machines will be more and more parallel, so take advantage of that.
  • ucontext was removed from the standards and might not be supported in future OS's (or even some present ones?)
  • Rolling your own threads cannot be made transparent to library code you might want to use. It might break library code that makes reasonable assumptions about concurrency, locking, etc. As long as your multithreading is cooperative rather than async-signal-based there are probably not too many issues like this, but once you've gotten this deep into nonportable hacks things can get very fragile.
  • ...and probably some more reasons I can't think of right now. :-)
R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • For all intents and purposes, `ucontext` is still “portable.” OS vendors hardly remove any API that was ever introduced by POSIX and `ucontext` is a particularly small API with no reason to remove it. – fuz Dec 26 '15 at 11:26
1

On the portability matter, setjmp() is portable to all hosted C implementations; the <ucontext.h> functions are part of the XSI extensions to POSIX - this makes setjmp() significantly more portable.

It is possible to use setjmp() in a thread-safe manner. It doesn't make much sense to use the ucontext functions in a threaded program - you would use multiple threads rather than multiple contexts.

Use setjmp() if you want to quickly return from a deeply-nested function call (this is why you find that most examples show its use for exception handling). Use the ucontext functions for implementing user-space threads or coroutines (or don't use them at all).

The "fast and secure" question makes no sense. The implementations are typically as fast as it is practical to make them, but they perform different functions so cannot be directly compared (the ucontext functions do more work, so will typically be slightly slower).

Note that the ucontext functions are listed as obsolescent in the two most recent editions of POSIX. The pthreads threading functions should generally be used instead.

caf
  • 233,326
  • 40
  • 323
  • 462
  • As far as I can tell, the `ucontext` functions were removed from POSIX 2008, not just marked obsolescent. Only the structures remain, and they were moved to `signal.h`. They are still provided via the third argument to a `SA_SIGINFO` signal handler (see my recent question and self-answer for a potential use). – R.. GitHub STOP HELPING ICE Apr 05 '11 at 12:20
0

setjmp/longjmp are only intended to restore a "calling" context, so you can use it only to do a "fast exit" from a chain of subroutines. Different uses may or may not work depending on the system, but in general these functions are not intended to do this kind of things. So "ucontext" is better. Also have a look to "fibers" (native on Windows). Here a link to an article that may be helpful:

How to implement a practical fiber scheduler?

Bye!

Community
  • 1
  • 1
Giuseppe Guerrini
  • 4,274
  • 17
  • 32