Implementing simple cooperative threads in C • Hacker News Board

Re: Implementing simple cooperative threads in C

#81

Post by kccqzy » Mon, May 25, 2020, 8:17 PM UTC

Blackthorn wrote: post #78

kccqzy wrote: post #74

Earlier quoted context omitted.

> Various languages have "solved" this by not allowing you to use blocking calls That is the right solution. Do you seriously think in Go when you make an apparently blocking system call, an actual blocking system call is made? No, you are calling the runtime provided version that doesn't actually block. Of course in C/C++ that needs more discipline to do.

> Do you seriously think in Go when you make an apparently blocking system call, an actual blocking system call is made? Who cares? From the perspective of the programmer, it's a blocking call.

Then how is a syntactic construct like "await blocking_call()" inferior? I fail to see your point. The await keyword even signals to you the fact that this call may be blocking the progress of the current fiber/coroutine.

And back to the original example, it's totally possible for a production implementation to handhold the user like this by, e.g. supplying a modified libc so that all the blocking system calls are linked against the runtime's implementation. That would basically achieve what you liked in Go.

Re: Implementing simple cooperative threads in C

#82

Post by Blackthorn » Tue, May 26, 2020, 2:22 AM UTC

kccqzy wrote: post #81

Blackthorn wrote: post #78

Earlier quoted context omitted.

> Do you seriously think in Go when you make an apparently blocking system call, an actual blocking system call is made? Who cares? From the perspective of the programmer, it's a blocking call.

Then how is a syntactic construct like "await blocking_call()" inferior? I fail to see your point. The await keyword even signals to you the fact that this call may be blocking the progress of the current fiber/coroutine. And back to the original example, it's totally possible for a production implementation to handhold the user like this by, e.g. supplying a modified libc so that all the blocking system calls are li…

> Then how is a syntactic construct like "await blocking_call()" inferior?

It's inferior because you have to actually specify it whenever you make such a call, rather than having the runtime or library be smart and figure it out.

> And back to the original example, it's totally possible for a production implementation to handhold the user like this by, e.g. supplying a modified libc so that all the blocking system calls are linked against the runtime's implementation.

I know. I didn't say it was intractable. Just like problems 1-3, they all have potential solutions -- they just involve hard work.

Re: Implementing simple cooperative threads in C

#83

Post by winrid » Tue, May 26, 2020, 6:21 AM UTC

retSava wrote: post #77

winrid wrote: post #71

Earlier quoted context omitted.

And it will keep happening, because there are many more people starting programming each year than old people that can teach them.

And it's a Good Thing, since it fosters a inventive way of thinking around a problem rather than just reading/hearing that X exists, download that and be done. It's part of learning and honing a skill. This doesn't mean that the implementation should then be used in practice, there are likely other solutions that are better suited, more mature, etc.

I agree!

Re: Implementing simple cooperative threads in C

#84

Post by [deleted] » Tue, May 26, 2020, 7:37 AM UTC

anonymoushn wrote: post #66

greggman3 wrote: post #58

This style of coop multi-tasking was in Crash Team Racing on PS1 for a while. Unfortunately on a machine with only 2meg of ram it turned out to take too much memory and be too fragile. The stacks had to be small, add one printf for debugging and you'd overflow the stack. Eventually it was torn out.

I'm surprised you didn't pile on by making a printf which switches to the main stack, does the actual printf, and switches back.

[deleted]

Re: Implementing simple cooperative threads in C

#85

Post by greggman3 » Tue, May 26, 2020, 7:41 AM UTC

anonymoushn wrote: post #66

greggman3 wrote: post #58

This style of coop multi-tasking was in Crash Team Racing on PS1 for a while. Unfortunately on a machine with only 2meg of ram it turned out to take too much memory and be too fragile. The stacks had to be small, add one printf for debugging and you'd overflow the stack. Eventually it was torn out.

I'm surprised you didn't pile on by making a printf which switches to the main stack, does the actual printf, and switches back.

printf was just an obvious example. Any function had this problem. You run, things work, and then under some condition the function you called called something else and crash. Or you try to add some functionality to a function in the system and suddenly the tasks crash because your edit used more stack.

The point isn't to dis this method. It's just to say it was frustrating with tiny stacks.

Re: Implementing simple cooperative threads in C

#86

Post by greggman3 » Tue, May 26, 2020, 7:44 AM UTC

aktau wrote: post #80

greggman3 wrote: post #58

This style of coop multi-tasking was in Crash Team Racing on PS1 for a while. Unfortunately on a machine with only 2meg of ram it turned out to take too much memory and be too fragile. The stacks had to be small, add one printf for debugging and you'd overflow the stack. Eventually it was torn out.

What was it replaced with?

The typical

    for g of gameobject
      g.update()

Re: Implementing simple cooperative threads in C

#87

Post by anonymoushn » Tue, May 26, 2020, 8:28 AM UTC

greggman3 wrote: post #85

anonymoushn wrote: post #66

Earlier quoted context omitted.

I'm surprised you didn't pile on by making a printf which switches to the main stack, does the actual printf, and switches back.

printf was just an obvious example. Any function had this problem. You run, things work, and then under some condition the function you called called something else and crash. Or you try to add some functionality to a function in the system and suddenly the tasks crash because your edit used more stack. The point isn't to dis this method. It's just to say it was frustrating with tiny stacks.

I see, that does sound tough.

Re: Implementing simple cooperative threads in C

#88

Post by kccqzy » Tue, May 26, 2020, 7:00 PM UTC

Blackthorn wrote: post #82

kccqzy wrote: post #81

Earlier quoted context omitted.

Then how is a syntactic construct like "await blocking_call()" inferior? I fail to see your point. The await keyword even signals to you the fact that this call may be blocking the progress of the current fiber/coroutine. And back to the original example, it's totally possible for a production implementation to handhold the user like this by, e.g. supplying a modified libc so that all the blocking system calls are li…

> Then how is a syntactic construct like "await blocking_call()" inferior? It's inferior because you have to actually specify it whenever you make such a call, rather than having the runtime or library be smart and figure it out. > And back to the original example, it's totally possible for a production implementation to handhold the user like this by, e.g. supplying a modified libc so that all the blocking system ca…

I see what you mean now. Omitting the keyword "await" is incredibly easy to do; simply do something different when the returned type is an awaitable. But the fact is that most languages haven't done this, and have you considered that perhaps language designers considered this issue and decided that explicit is better than implicit? And there are also a whole host of other issues too.