3 ms·
Not only that, but there's a multiprocess Queue class as well that is a drop in replacement for the threaded one. So if you are having problems with GIL conten
by dignan 14y ago
Not only that, but there's a multiprocess Queue class as well that is a drop in replacement for the threaded one. So if you are having problems with GIL contention (unlikely, but possible), you can still just as easily use multiple processes.
- cgh 14y agoExactly what I thought - "what about multiprocessing?" Doesn't that count as language-level concurrency support? You can fire off a background job to send email or whatever just as easily as in the Go example.
- milesvp 14y agoThis confused me as well, it felt like the author was thinking about the problem space all wrong. As soon as I read "As a Django developer, there wasn’t a straightforward and obvious way to just do things in the background on a page request" I started thinking, "um, django produces http responses, you can only respond once...". Clearly, from his gevents example, he's looking to do things that take time, and wants to do them as concurrently as possible, then send the whole response at once. But if he really doesn't want the user to wait, then this is not something you should be doing in a webserver anyways. You really should be building that into the front end javascript, and let it handle all the async data grabs from small, fast, cacheable web requests, then redraw the page as the data comes in.
- slurgfest 14y agoIf for whatever reason you don't want to build everything into the front end Javascript, it is very common to throw jobs onto a task queue to be done outside of the HTTP flow, so they do not block the response. This could be a lot more accessible to beginners, however, because there are moving pieces like a message queue that have to be set up and blah blah.