21–30 of 40 posts
Earlier quoted context omitted.
waitAll gone. Before I put it in any package managers it will get style guided. This is currently on version -1.0.0.
> version -1.0.0. Version negative one? I don't think I've ever seen that before. Usually, the very earliest versions of software are numbered like 0.0.1 or something like that.
Earlier quoted context omitted.
> version -1.0.0. Version negative one? I don't think I've ever seen that before. Usually, the very earliest versions of software are numbered like 0.0.1 or something like that.
- here actually negates the ordering of the numbers in the list. -1.0.0 === 0.0.1.
Well, I've certainly never seen that before.
Earlier quoted context omitted.
Single-core concurrency is concurrency is concurrency (you have different computations occurring concurrently, even if they are not executing at the same time). What it's not is parallelism.
Concurrent means at the same time. You can't have things happening concurrently but not at the same time.
Earlier quoted context omitted.
It appears to add some amount of Python-bytecode level preemption to gevent, which allows you to hopefully avoid some of the pathological cases of cooperative scheduling. Said pathological cases are only a matter of scale... if your program becomes large enough, you will hit them, eventually. That said, with no offense intended to mirman, I'd really hesitate before using this for anything serious enough to reach that…
what are the pathological cases one runs into with gevent?
You can hack around many of them, but you eventually hit a wall, and the effort of the hack increases rapidly.
Note I didn't really use gevent in this reply, this is just about cooperative scheduling. There's a reason why we've all but completely abandoned it at the OS level for things we'd call "computers" (as opposed to "embedded systems" or "microcontrollers", etc). I tend to consider cooperative scheduling an enormous red flag in any system that uses it... and yes, that completely and fully includes the currently-popular runtimes that use it.
Earlier quoted context omitted.
Concurrent means at the same time. You can't have things happening concurrently but not at the same time.
This may help explain the difference: http://blog.golang.org/concurrency-is-not-parallelism
If one of them should mean one thing and the other the other why not have the one that literally means at the same time for the term that means at the same time. And have the one that means non intersecting mean threads of execution that are beside each other but not touching without lots of pain and suffering. Sorry, rant bit off.
The resounding question in my mind is why this, when there is Stackless Python? What's better about this greenthreading impl? http://www.stackless.com/
If I'd had the option to switch us to stackless easily, and I could guarantee it was as fast, worked with all the libraries, and was as stable, I probably wouldn't have written this. I imagine that there are a lot of people in the same boat, where switching interpreters isn't really an option.
Earlier quoted context omitted.
what are the pathological cases one runs into with gevent?
With a cooperative scheduler, you will , sooner or later, experience some form of starvation. The most obvious is the process that just infinitely loops, but less obvious situations will end up popping up too; calls that you thought were handled by the event loop but turn out to be blocking and add up when you start calling them at scale, strange behavior when you have a set of processes that turn out to yield far le…
This library is probably nice for the places I would otherwise use threads.
I don't really get what advantage this gives me beyond using gevent. There's still no parallelism. The readme describes it as "A solution to concurrency," but I already get that using gevent. Is it just to improve communication between green threads?
Earlier quoted context omitted.
The lack of options for parallel (and non-parallel) concurrency is, along with other things, feeding the high defection rate to many other languages.
We've had processes, threads and greenlets for a while now... if anything the problem isn't that there are no options, but too many options that require understanding to choose and apply. Many of the people complaining about this issue don't have a demonstrated problem and could try any simple approach first (if the point is not just to slam Python in favor of something else, from the beginning).
I am not really a Go proponent. I'm a Haskell user, personally, and Haskell, like Python, has three or four options that require understanding to choose and apply. The difference there being that in Haskell, each one of them actually gets you real parallelism, no fine print necessary. I bring it up to point out that the situation with Python is not a good example of what you might call "intrinsic complexity" (as you seem to be implying) or the Go solution would not be so much simpler, nor is it really an example of there being many better higher-level abstractions, or more of them would resemble Haskell's many high-level options. It is simply a bad situation that produces many poor kludges, and the mentality that everything is fine is (in my opinion) feeding a substantial defection rate to Go.