5 ms·
I know, I know. Why is it so important that someone else did something conceptually similar once upon a time? Can't you see the value in standing on their shoul
by codr4life 10y ago
I know, I know. Why is it so important that someone else did something conceptually similar once upon a time? Can't you see the value in standing on their shoulders and try to reach further in some direction? We're all in the same boat here, you can't own ideas. In this case I was aiming to simplify API and usage while keeping the performance, and I feel I managed to take at least a few steps in that direction.
- scandox 10y agoWell it is useful for others to know the history and have other references. I am sure it is not intended to diminish your work.
- codr4life 10y agoBut where do we stop? In the end it's also based on K&R, and on BCPL, and...
- drakehutner 10y agoExactly that! Sorry if my comment came across like an insult. Wasn't intended as such. Maybe it was just me hoping to find a direct improvement of Tathams implementation. Which I would call "quirky" at best. Your implementation seems to be much more "useable" and understandable in comparison. After reading through more of your library I must say, I like it's style.
- fanf2 10y agoIt's worth noting that Tatham's coroutines are very widely deployed in PuTTY
- drakehutner 10y agoI believe Putty is part of the reason why they exists. Every author is able to employ his own mad creations (Speaking from experience here). I have never seen his coroutine someplace else with the single exception of the above mentioned contiki / protothreads.
- codr4life 10y agoNone of this is personal to me, I have no idea where the inspiration came from; I'm just trying to share the beauty I see in the concepts. So I get a bit frustrated with anything that steals focus from my mission, like history lessons. I don't really care who thought of what first. Sorry if that came across as hurt feelings, there is no conflict here. I'm glad you like the humble beginnings of the library I've always been wishing for :)
- drakehutner 10y agoThis makes your work even more interesting. I don't know if you read the original Mail [1] in which Tom Duff shared his Device, but at the end he's mentioning that he had an idea for something like coroutines: > It amazes me that after 10 years of writing C there are still little corners that I haven't explored fully. (Actually, I have another revolting way to use switches to implement interrupt driven state machines but it's too horrid to go into.) He later replied to Simon Tatham, that his coroutines actually where those "horrid" ideas. Obviously you must had some thoughts similar to those two. Kudos for that. You seem to to have a deep understanding of the concepts that make the C language (and how to twist them) ;). [1]: http://www.lysator.liu.se/c/duffs-device.html http://www.lysator.liu.se/c/duffs-device.html
- enqk 10y agoAs scandox I did not mean to be dismissive, just to highlight the technique has been used in the past, as a reference for discussion and evaluation. It is hard to imagine how one could preserve local variables w/o knowledge about the precise compiler + architecture. You would also have to communicate to the compiler that these locals should not be re-arranged nor merged in every context where the function is being used. So the pragmatic solution thus far has been to keep track of variables in a separate block of memory, passed in in every invocation of a coroutine.
- codr4life 10y agoPreservation of stack data is done by comparing addresses of stack allocated values and using memcpy to copy the space in between. That's the most straight forward solution I could come up with. I'm still working on a way to track the variables automagically, which is why the optimization level is set to 0 for now; looks like I might end up having to add a third macro for preserved vars.