Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Cooperative multithreading via setjmp and longjmp has been around in C since the 80s at least.

I’m not sure this is so much hacking as an accepted technique from the old-old days which has somewhat fallen out of favour, especially as C is falling a little outside of the mainstream these days.

Perhaps it’s almost becoming lost knowledge :)



This isn't using setjmp/longjmp

It's using Simon Tatham's method based on Duff's device (https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html)


Sure, I guess I just wanted to point out that regardless of method, people have been building these sorts of facilities in C for a very long time.

It doesn’t lessen the achievement of course, but it amuses me an in “everything old is new again” kinda way.


"everything old is new again" is so true. I see it across IT all the time, heh.


One of the most surprising things I discovered a while back is that this technique not only technically works in JavaScript, it actually beats its own built-in generator syntax in performance terms even if used as an iterable object:

https://jsbenchit.org/?src=1b165435c816c6d298e6b800b4742568

https://jsbenchit.org/?src=dedb07499cfa289b94d686bde05901df

Context: JS has an iteration protocol[0] that lets you create your own custom objects to be used with syntactic sugar for iteration. The sensible expectation is that the built-in syntax for generating such functions would produce the fastest code. It clearly doesn't.

Having said that I do not recommend manually writing code this way because if this is something that you need to worry about while writing JavaScript, it's a sign that you're using the wrong tool for the job anyway.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...


Also wanted to add that while I think this is very clever, and I am a big fan of Mr Tatham's work, that by the time we're talking about the 'advanced' version at the end we're edging towards using a stack-based system in the form of a context object and at that point it feels like we're just a leap and a jump to stack-based coroutines and full-on cooperative multithreading.

Also, by the time you're passing a coroutine context around anyway, you could refactor (say) the decompressor around a decompression context and the code would stay nice...

It's definitely interesting though, and it's been a few years since I read that coroutines page.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: