Marko Rauhamaa writes:
> Mostly asyncio is a way to deal with anything you throw at it. What do
> you do if you need to exit the application immediately and your threads
> are stuck in a 2-minute timeout?
Eh? When the main thread exits, all the child threads go with it.
Sometimes there is some
Marko Rauhamaa writes:
> That's a good reason to avoid threads. Once you realize you would have
> been better off with an async approach, you'll have to start over.
That just hasn't happened to me yet, at least in terms of program
organization. Python threads get too slow once there are too many
On Wed, Jun 4, 2014 at 3:10 PM, Burak Arslan wrote:
> Ah ok. Well, a couple of years of writing async code, my not-so-objective
> opinion about it is that it forces you to split your code into functions,
> just like Python forces you to indent your code properly. This in turn
> generally helps the
On 03/06/14 14:57, Chris Angelico wrote:
On Tue, Jun 3, 2014 at 9:05 PM, Burak Arslan wrote:
On 06/03/14 12:30, Chris Angelico wrote:
Write me a purely nonblocking
web site concept that can handle a million concurrent connections,
where each one requires one query against the database, and one
Chris Angelico :
> Okay. How do you do basic logging? (Also - rolling your own logging
> facilities, instead of using what Python provides, is the simpler
> solution? This does not aid your case.)
Asyncio is fresh out of the oven. It's going to take years before the
standard libraries catch up wi
In article <87ha42uos2@elektro.pacujo.net>,
Marko Rauhamaa wrote:
> Chris Angelico :
>
> > I don't see how Marko's assertion that event-driven asynchronous
> > programming is a breath of fresh air compared with multithreading. The
> > only way multithreading can possibly be more complicated
On Tue, Jun 3, 2014 at 11:42 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> https://docs.python.org/3.4/library/logging.html#logging.Logger.debug
>>
>> What happens if that blocks? How can you make sure it won't?
>
> I haven't used that class. Generally, Python standard libraries are not
> read
Chris Angelico :
> https://docs.python.org/3.4/library/logging.html#logging.Logger.debug
>
> What happens if that blocks? How can you make sure it won't?
I haven't used that class. Generally, Python standard libraries are not
readily usable for nonblocking I/O.
For myself, I have solved that par
On Tue, Jun 3, 2014 at 11:05 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> I don't see how Marko's assertion that event-driven asynchronous
>> programming is a breath of fresh air compared with multithreading. The
>> only way multithreading can possibly be more complicated is that
>> preemptio
Chris Angelico :
> I don't see how Marko's assertion that event-driven asynchronous
> programming is a breath of fresh air compared with multithreading. The
> only way multithreading can possibly be more complicated is that
> preemption can occur anywhere - and that's exactly one of the big
> flaw
On Tue, Jun 3, 2014 at 9:09 PM, Frank Millman wrote:
> So why not keep a 'connection pool', and for every potentially blocking
> request, grab a connection, set up a callback or a 'yield from' to wait for
> the response, and unblock.
Compare against a thread pool, where each thread simply does bl
On Tue, Jun 3, 2014 at 9:05 PM, Burak Arslan wrote:
> On 06/03/14 12:30, Chris Angelico wrote:
>> Write me a purely nonblocking
>> web site concept that can handle a million concurrent connections,
>> where each one requires one query against the database, and one in a
>> hundred of them require f
Chris Angelico :
> your throughput is defined by your database.
Asyncio is not (primarily) a throughput-optimization method. Sometimes
it is a resource consumption optimization method as the context objects
are lighter-weight than full-blown threads.
Mostly asyncio is a way to deal with anything
"Chris Angelico" wrote in message
news:captjjmqwkestvrsrg30qjo+4ttlqfk9q4gabygovew8nsdx...@mail.gmail.com...
>
> This works as long as your database is reasonably fast and close
> (common case for a lot of web servers: DB runs on same computer as web
> and application and etc servers). It's nice
On 06/03/14 12:30, Chris Angelico wrote:
> Write me a purely nonblocking
> web site concept that can handle a million concurrent connections,
> where each one requires one query against the database, and one in a
> hundred of them require five queries which happen atomically.
I don't see why tha
On Tue, Jun 3, 2014 at 8:08 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Okay, but how do you handle two simultaneous requests going through
>> the processing that you see above? You *MUST* separate them onto two
>> transactions, otherwise one will commit half of the other's work.
>
> I will
Chris Angelico :
> Okay, but how do you handle two simultaneous requests going through
> the processing that you see above? You *MUST* separate them onto two
> transactions, otherwise one will commit half of the other's work. (Or
> are you forgetting Databasing 101 - a transaction should be a logi
On Tue, Jun 3, 2014 at 7:10 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> def request.process(self): # I know this isn't valid syntax
>> db.act(whatever) # may block but shouldn't for long
>> db.commit() # ditto
>> write(self, response) # won't block
>>
>> This works as long as you
Chris Angelico :
> def request.process(self): # I know this isn't valid syntax
> db.act(whatever) # may block but shouldn't for long
> db.commit() # ditto
> write(self, response) # won't block
>
> This works as long as your database is reasonably fast and close
I find that assumption
On Tue, Jun 3, 2014 at 4:36 PM, Marko Rauhamaa wrote:
> I have yet to see that in practice. The "typical" thread works as
> follows:
>
> while True:
> while request.incomplete():
> request.read() # block
> sql_stmt = request.process()
> db.ac
Hello,
On Mon, 02 Jun 2014 21:51:35 -0400
Terry Reedy wrote:
> To all the great responders. If anyone thinks the async intro is
> inadequate and has a paragraph to contribute, open a tracker issue.
Not sure about intro (where's that?), but docs
(https://docs.python.org/3/library/asyncio.html)
Paul Rubin :
> Marko Rauhamaa writes:
>> - Thread programming assumes each thread is waiting for precisely
>> one external stimulus in any given state -- in practice, each
>> state must be prepared to handle quite a few possible stimuli.
>
> Eh? Threads typically have their own e
I haven't worked with asynchronous tasks or concurrent programming so far. Used
VB2010 and have used some jQuery in a recent project but nothing low level.
As per the explanation it seems that programming using asyncio would require
identifying blocks of code which are not dependent on the IO. W
To all the great responders. If anyone thinks the async intro is
inadequate and has a paragraph to contribute, open a tracker issue.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, Jun 3, 2014 at 6:45 AM, Paul Rubin wrote:
>> - Thread-safe programming is easy to explain but devilishly
>> difficult to get right.
>
> I keep hearing that but not encountering it. Yes there are classic
> hazards from sharing mutable state between threads. However, it's
> gener
On 06/02/14 20:40, Aseem Bansal wrote:
> I read in these groups that asyncio is a great addition to Python 3. I have
> looked around and saw the related PEP which is quite big BTW but couldn't
> find a simple explanation for why this is such a great addition. Any simple
> example where it can b
Marko Rauhamaa writes:
> - Thread programming assumes each thread is waiting for precisely
> one external stimulus in any given state -- in practice, each
> state must be prepared to handle quite a few possible stimuli.
Eh? Threads typically have their own event loop dispatching
Terry Reedy :
> I do not understand this. asyncio should switch between tasks faster
> than the OS switches between threads, thus reducing waiting time.
I don't know if thread switching is slower than task switching. However,
there are two main reasons to prefer asyncio over threads:
* Scalabil
In article ,
Terry Reedy wrote:
> asyncio lets you write platform independent code while it makes good use
> of the asynchronous i/o available on each particular system. Async-i/o
> is one area where Windows has made advances over posix. But the models
> are different, and if one uses Windows
On 6/2/2014 1:40 PM, Aseem Bansal wrote:
The following supplement Ian's answer.
I read in these groups that asyncio is a great addition to Python 3.
I have looked around and saw the related PEP which is quite big BTW
but couldn't find a simple explanation for why this is such a great
addition.
On Mon, Jun 2, 2014 at 11:40 AM, Aseem Bansal wrote:
> I read in these groups that asyncio is a great addition to Python 3. I have
> looked around and saw the related PEP which is quite big BTW but couldn't
> find a simple explanation for why this is such a great addition. Any simple
> example
I read in these groups that asyncio is a great addition to Python 3. I have
looked around and saw the related PEP which is quite big BTW but couldn't find
a simple explanation for why this is such a great addition. Any simple example
where it can be used?
It can be used to have a queue of task
32 matches
Mail list logo
