News for hackers. Stuff that matters.
Re:Re: 100k Threads? (2002) by fiedzia on Saturday September 23, 2023 @11:46AM (#37624303)
> without using a bunch of excess thread context resources

If the threads are cheap, there is no point in making this distinction, which greatly simplifies the language. And they can be, we just need programming languages designed for that.

Re:Re: 100k Threads? (2002) by ttfkam on Saturday September 23, 2023 @12:22PM (#37624646)
Non-blocking I/O channels use fewer threads (native or green) than tasks. Some programming languages ARE designed to handle this: they use async/await.

You could argue that Go does this more elegantly with goroutines, but this further highlights the point that threads should not be a silver bullet to development models.

Re:Re: 100k Threads? (2002) by the_biot on Saturday September 23, 2023 @11:15PM (#37629852)
Here, here. The elephant in the room in just about any discussion about threads/async is Python. Threads simply don't function in Python because of the GIL.

Instead of accepting this fact and using another language if threads are needed, Python has been doing various async-style things for years and pretending it's good enough, including what can only be described as cooperative multitasking, that horror from the early 90s.

Re:Re: 100k Threads? (2002) by fiedzia on Sunday September 24, 2023 @04:35AM (#37631193)
Python is working on removing GIL (I am not sure about timeframe) and will have subinterpreters - the last one will come in 3.13 and solves the thread problem.
Re:Re: 100k Threads? (2002) by ttfkam on Monday September 25, 2023 @11:58PM (#37654152)
Some people, when confronted with a problem, think, “I know, I’ll use threads,” and then two they hav erpoblesms. – Ned Batchelder