11–20 of 40 posts
> Conpig threads still can only run on one core of a processor. This isn't true concurrency. Scaling to 20 million requests per second over 40 cores on a single machine is true concurrency.
[1] http://en.wikipedia.org/wiki/Concurrency_(computer_science)
> Conpig threads still can only run on one core of a processor. This isn't true concurrency. Scaling to 20 million requests per second over 40 cores on a single machine is true concurrency.
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?
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…
There is a version in the history that used Greenlet instead of gevent which was potentially a bit less delicate, but it required wrapping of the main file and didn't work with time.sleep, and I didn't feel like it was worth writing my own locks, semaphores, mutexes, pipes and whatnot.
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).
As someone who has had to ship stuff using multiprocess & gevent to actually meet real world scaling needs -- and integrating them with C code and communicating to a C++ application via ZMQ (inprocess by sharing the object) ... the sad fact is once we started to tackle really hard problems in Python that aren't pre-solved via a nice library all those early advantages fell away and we craved the blessed simplicity of C++ (note: sarcasm, C++ isn't simple, but it was far simpler than the Frankenstein's monster we built).
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?
Fewer explicit yields & no monkey patching necessary for IO performing libraries.
> Conpig threads still can only run on one core of a processor. The disillusionment caused by having so many options for non-parallel "concurrency" in Python is, I believe, feeding the high defection rate from Python to Go.
Yes, you absolutely can use all your cores by combining multiprocess, gevent and custom C code. But, debugging that stack of a level of hell I will never return too, ever.
> Conpig threads still can only run on one core of a processor. This isn't true concurrency. Scaling to 20 million requests per second over 40 cores on a single machine is true concurrency.
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.
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?
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…
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.
But what a "thing" and how long a period is are up for grabs. If we choose period to be anything longer than 1 millisecond, then this library will finish executing both things in that time period.
http://stackoverflow.com/questions/1050222/concurrency-vs-pa...
Since this is a very new project, it is a good time to suggest that you abide by PEP8 (e.g., no 'waitAll') since this would be widely appreciated, and is not easy to fix later on.
waitAll gone. Before I put it in any package managers it will get style guided. This is currently on 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.