2 ms·

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 https://w

by ajb 1y ago

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 https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html)

Nursie 1y ago
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.
- johnisgood 1y ago
  "everything old is new again" is so true. I see it across IT all the time, heh.
vanderZwan 1y ago
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=1b165435c816c6d298e6b800b4742568 https://jsbenchit.org/?src=dedb07499cfa289b94d686bde05901df 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/Reference/Iteration_protocols#the_iterable_protocol https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Nursie 1y ago
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.

by ajb 1y ago

Nursie 1y ago

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.

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

vanderZwan 1y ago

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=1b165435c816c6d298e6b800b4742568 https://jsbenchit.org/?src=dedb07499cfa289b94d686bde05901df 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/Reference/Iteration_protocols#the_iterable_protocol https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Nursie 1y ago

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.