3 ms·

That's just not possible, and for good reason: some things happen now, and some things happen later, and if you need ultra-fine-grained control over what happen

That's just not possible, and for good reason: some things happen now, and some things happen later, and if you need ultra-fine-grained control over what happens when, then you need to be very explicit about what's happening and how and when. Green threads. No silver bullet, but sometimes you upgrade your pistol. JS needs greenthreads. There's no reason you shouldn't just spin up a thread for every blocking context. This is arguably what async/await already does, but you don't have control over the toplevel loop. Point out where your while (userIsOnWebsite) { ... } loop is. :) Having a toplevel loop is very important for simplicity -- but even moreso for what you mention: having ultra fine-grained control, and not constantly fighting with the underlying scheduler / ecosystem.

meowface 8y ago
I've seen a lot of debate over this, but I find greenthreads so much simpler to work with and reason about, on top of keeping my code clean and completely interoperable with my synchronous code. This is off-topic from the current JavaScript discussion, but even though Python introduced "first-class" async support a while ago, I still exclusively use gevent [1] for all of my concurrency needs. It provides full greenthread support for Python. It's extremely performant on top of being simple and clean to integrate. In contrast, Python's asyncio and async/await feels needlessly verbose and tortuous, often with full rewrites or replacements of libraries required to actually take advantage of the features (e.g. https://github.com/requests/requests https://github.com/requests/requests vs. https://github.com/aio-libs/aiohttp https://github.com/aio-libs/aiohttp). With gevent, I can just put whatever code I want into a greenthread and get instant asynchronicity (excluding hiccups with a few 3rd party libraries that have network I/O in native extensions, which is rare). The one downside is it achieves its magic with standard library monkeypatching, which is pretty hideous, but it's done very seamlessly. Developers are able to write the exact same code with or without monkeypatching and not worry about what it's doing. I've never encountered an issue with the monkeypatching when using any standard or 3rd party library. [1] http://www.gevent.org/ http://www.gevent.org/
- millstone 8y ago
  How does gevent handle spawning kernel threads? Last time I tried Go I found that it spawned unlimited kernel threads. For example, a thousand goroutines calling stat() would result in as many kernel threads. I ended up tracking down which goroutines were likely to spawn kernel threads (gross global reasoning), and applied a rate-limiter to that set.
  - meowface 8y ago
    Unfortunately, Python is still bound by the GIL, so to my understanding, gevent will never spawn any kernel threads. This effectively means there is no true parallelism possible; context switches between greenthreads pretty much only occur when waiting on I/O. I believe this is the case for all other Python concurrency libraries as well, including the threading library in Python's standard lib. Most people, including myself, use gevent for I/O bound applications (where it excels), so this usually doesn't pose any issues. For CPU bound tasks where performance is important, I'd probably use something other than Python (likely Go, personally).

meowface 8y ago

I've seen a lot of debate over this, but I find greenthreads so much simpler to work with and reason about, on top of keeping my code clean and completely interoperable with my synchronous code. This is off-topic from the current JavaScript discussion, but even though Python introduced "first-class" async support a while ago, I still exclusively use gevent [1] for all of my concurrency needs. It provides full greenthread support for Python. It's extremely performant on top of being simple and clean to integrate. In contrast, Python's asyncio and async/await feels needlessly verbose and tortuous, often with full rewrites or replacements of libraries required to actually take advantage of the features (e.g. https://github.com/requests/requests https://github.com/requests/requests vs. https://github.com/aio-libs/aiohttp https://github.com/aio-libs/aiohttp). With gevent, I can just put whatever code I want into a greenthread and get instant asynchronicity (excluding hiccups with a few 3rd party libraries that have network I/O in native extensions, which is rare). The one downside is it achieves its magic with standard library monkeypatching, which is pretty hideous, but it's done very seamlessly. Developers are able to write the exact same code with or without monkeypatching and not worry about what it's doing. I've never encountered an issue with the monkeypatching when using any standard or 3rd party library. [1] http://www.gevent.org/ http://www.gevent.org/

millstone 8y ago
How does gevent handle spawning kernel threads? Last time I tried Go I found that it spawned unlimited kernel threads. For example, a thousand goroutines calling stat() would result in as many kernel threads. I ended up tracking down which goroutines were likely to spawn kernel threads (gross global reasoning), and applied a rate-limiter to that set.
- meowface 8y ago
  Unfortunately, Python is still bound by the GIL, so to my understanding, gevent will never spawn any kernel threads. This effectively means there is no true parallelism possible; context switches between greenthreads pretty much only occur when waiting on I/O. I believe this is the case for all other Python concurrency libraries as well, including the threading library in Python's standard lib. Most people, including myself, use gevent for I/O bound applications (where it excels), so this usually doesn't pose any issues. For CPU bound tasks where performance is important, I'd probably use something other than Python (likely Go, personally).