Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #98678
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: cross platform alternative for signal.SIGALRM? |
| Date | 2015-11-12 18:37 +1100 |
| Message-ID | <mailman.256.1447313831.16136.python-list@python.org> (permalink) |
| References | <n1vpl3$hrl$1@news2.informatik.uni-stuttgart.de> <mailman.251.1447292269.16136.python-list@python.org> <877flnu4kn.fsf@elektro.pacujo.net> <n21cb4$agq$1@dont-email.me> |
On Thu, Nov 12, 2015 at 5:43 PM, Christian Gollwitzer <auriocus@gmx.de> wrote:
> My understanding of async is that it creates an event loop. In which case
> the loop has no chance to run within a block of code that computes anything,
> is that correct?
This is correct. At its simplest, asynchronous code is an abstraction
over the select() call, which basically says "Hey system, tell me when
(a) I can read from here, (b) I can write to here, or (c) I've been
waiting this long". The most common use is sockets; a web server has
its main listening socket (it becomes readable when someone connects),
any clients that haven't finished sending their requests yet (they
become readable when more data arrives), any clients that you're still
sending to (they become writeable when there's room in their output
buffers), and maybe some sort of periodic checks ("every hour, do
maintenance"). Whenever you finish a bit of processing (reading from a
client, sending to a client, whatever), you return to the "event
loop", which in this case would be select().
An async library makes all this look a lot cleaner in your code, but
ultimately, it's not preemptive. You still have to make sure the
processing doesn't take too long.
ChrisA
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
cross platform alternative for signal.SIGALRM? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-11 16:16 +0000
Re: cross platform alternative for signal.SIGALRM? Marko Rauhamaa <marko@pacujo.net> - 2015-11-11 18:30 +0200
Re: cross platform alternative for signal.SIGALRM? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-11 17:06 +0000
Re: cross platform alternative for signal.SIGALRM? Marko Rauhamaa <marko@pacujo.net> - 2015-11-11 20:03 +0200
Re: cross platform alternative for signal.SIGALRM? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-11 22:42 +0000
Re: cross platform alternative for signal.SIGALRM? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-11-11 19:42 -0500
Re: cross platform alternative for signal.SIGALRM? Terry Reedy <tjreedy@udel.edu> - 2015-11-11 20:37 -0500
Re: cross platform alternative for signal.SIGALRM? Marko Rauhamaa <marko@pacujo.net> - 2015-11-12 08:14 +0200
Re: cross platform alternative for signal.SIGALRM? Christian Gollwitzer <auriocus@gmx.de> - 2015-11-12 07:43 +0100
Re: cross platform alternative for signal.SIGALRM? Chris Angelico <rosuav@gmail.com> - 2015-11-12 18:37 +1100
Re: cross platform alternative for signal.SIGALRM? Terry Reedy <tjreedy@udel.edu> - 2015-11-12 05:15 -0500
Re: cross platform alternative for signal.SIGALRM? Chris Angelico <rosuav@gmail.com> - 2015-11-12 22:38 +1100
Re: cross platform alternative for signal.SIGALRM? Terry Reedy <tjreedy@udel.edu> - 2015-11-12 09:01 -0500
Re: cross platform alternative for signal.SIGALRM? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-12 07:22 +0000
Re: cross platform alternative for signal.SIGALRM? Marko Rauhamaa <marko@pacujo.net> - 2015-11-12 10:15 +0200
Re: cross platform alternative for signal.SIGALRM? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-12 06:58 +0000
Re: cross platform alternative for signal.SIGALRM? Cameron Simpson <cs@zip.com.au> - 2015-11-12 16:20 +1100
csiph-web