1

I'm trying to port a library that uses ucontext over to a platform which supports pthreads but not ucontext. The code is pretty well written so it should be relatively easy to replace all the calls to the ucontext API with a call to pthread routines. However, does this introduce a significant amount of additional overhead? Or is this a satisfactory replacement. I'm not sure how ucontext maps to operating system threads, and the purpose of this facility is to make coroutine spawning fairly cheap and easy.

So, question is: Does replacing ucontext calls with pthread calls significantly change the performance characteristics of a library?

Robert Mason
  • 3,949
  • 3
  • 31
  • 44
  • [Co-Operative threading issue](http://stackoverflow.com/questions/4298986/is-there-something-to-replace-the-ucontext-h-functions) discussed. Overheads, I don't know. – जलजनक Oct 30 '12 at 18:08

1 Answers1

0

pthread is going to use system calls, and marginally some management memory. It should be comparable to ucontext assuming the same amount of system calls are needed (I would naively check that with strace).

For the same reason, swapcontext() is slower than using some longjmp trick (see this page for discussions where author claims 7x performance impact for his application).

I am not an expert on the subject, but I develop a library using coroutines spice-gtk, and we have backends using ucontext/jmp, gthread or winfibers. I didn't notice any performance changes with any, but that's probably because the lib is IO-bound in general.

elmarco
  • 31,633
  • 21
  • 64
  • 68