On Sat, Nov 23, 2013 at 1:15 PM, Roy Smith wrote:
> (*) I'm not sure if real MUDs are programmed this way, but it's a
> plausible architecture. For simplicity sake, I'm assuming a
> single-threaded server.
Yeah, they certainly can. That's effectively the way that I programmed
the MUD kernel that
On Friday, 22 November 2013 18:15:10 UTC-8, Roy Smith wrote:
> In article ,
>
> Bhanu Karthik wrote:
>
>
>
> > please help me.. what does the following line do?
>
> >
>
> > read_sockets,write_sockets,error_sockets =
>
> > select.select
On Friday, 22 November 2013 18:29:12 UTC-8, Steven D'Aprano wrote:
> On Fri, 22 Nov 2013 17:42:07 -0800, Bhanu Karthik wrote:
>
>
>
> > please help me.. what does the following line do?
>
> >
>
> > read_sockets,write_sockets,error_socke
On Fri, 22 Nov 2013 17:42:07 -0800, Bhanu Karthik wrote:
> please help me.. what does the following line do?
>
> read_sockets,write_sockets,error_sockets =
> select.select(CONNECTION_LIST,[],[])
The select.select function takes three arguments (plus an optional
fourth):
s
In article ,
Bhanu Karthik wrote:
> please help me.. what does the following line do?
>
> read_sockets,write_sockets,error_sockets =
> select.select(CONNECTION_LIST,[],[])
This is a little tricky.
First,read the docs at http://docs.python.org/2/library/select.html.
Ther
please help me.. what does the following line do?
read_sockets,write_sockets,error_sockets = select.select(CONNECTION_LIST,[],[])
--
https://mail.python.org/mailman/listinfo/python-list
Am 09.05.2010 11:59, schrieb Lawrence D'Oliveiro:
In message,
exar...@twistedmatrix.com wrote:
On 07:48 am, l...@geek-central.gen.new_zealand wrote:
In message,
exar...@twistedmatrix.com wrote:
This is a good example of why it's a bad idea to use select on
Windows.
Instead, use WaitForMulti
In message ,
exar...@twistedmatrix.com wrote:
> On 07:48 am, l...@geek-central.gen.new_zealand wrote:
>
>>In message ,
>>exar...@twistedmatrix.com wrote:
>>
>>>This is a good example of why it's a bad idea to use select on
>>>Windows.
>>>Instead, use WaitForMultipleObjects.
>>
>>How are you suppo
2010/5/8 Antoine Pitrou :
> On Sat, 8 May 2010 13:47:53 +0200
> Giampaolo Rodolà wrote:
>>
>> Assuming loop() function does something like this:
>>
>> ...
>> select.select(r, w, e, timeout)
>> scheduler() # checks for scheduled calls to be
) function does something like this:
...
select.select(r, w, e, timeout)
scheduler() # checks for scheduled calls to be fired
...
...imagine a case where there's a connection (aka a dispatcher
instance) which does not receive or send any data *and* a scheduled
call which is suppo
On 07:48 am, l...@geek-central.gen.new_zealand wrote:
In message ,
exar...@twistedmatrix.com wrote:
This is a good example of why it's a bad idea to use select on
Windows.
Instead, use WaitForMultipleObjects.
How are you supposed to write portable code, then?
With WaitForMultipleObjects on
On Sat, 8 May 2010 13:47:53 +0200
Giampaolo Rodolà wrote:
>
> Assuming loop() function does something like this:
>
> ...
> select.select(r, w, e, timeout)
> scheduler() # checks for scheduled calls to be fired
> ...
>
> ...imagine a case where
> Why?
Assuming loop() function does something like this:
...
select.select(r, w, e, timeout)
scheduler() # checks for scheduled calls to be fired
...
...imagine a case where there's a connection (aka a dispatcher
instance) which does not receive or send any data
In message ,
exar...@twistedmatrix.com wrote:
> This is a good example of why it's a bad idea to use select on Windows.
> Instead, use WaitForMultipleObjects.
How are you supposed to write portable code, then?
--
http://mail.python.org/mailman/listinfo/python-list
On 7 May, 07:25 pm, p.f.mo...@gmail.com wrote:
On 7 May 2010 15:36, Giampaolo Rodol� wrote:
You can easily avoid this by setting a lower timeout when calling
asyncore.loop(), like 1 second or less (for example, Twisted uses
0.001 secs).
Thanks, that's what I was considering.
This is a good
Le Fri, 07 May 2010 21:55:15 +0200, Giampaolo Rodolà a écrit :
> Of course, but 30 seconds look a little bit too much to me, also because
> (I might be wrong here) I noticed that a smaller timeout seems to result
> in better performances.
That's probably bogus.
> Plus, if scheduled callbacks are
2010/5/7 Antoine Pitrou :
> Le Fri, 07 May 2010 16:36:44 +0200, Giampaolo Rodolà a écrit :
>> You can easily avoid this by setting a lower timeout when calling
>> asyncore.loop(), like 1 second or less (for example, Twisted uses 0.001
>> secs).
>> Actually there's no reason for asyncore to have suc
On 7 May 2010 15:36, Giampaolo Rodolà wrote:
> You can easily avoid this by setting a lower timeout when calling
> asyncore.loop(), like 1 second or less (for example, Twisted uses
> 0.001 secs).
Thanks, that's what I was considering.
> Actually there's no reason for asyncore to have such a high
Le Fri, 07 May 2010 16:36:44 +0200, Giampaolo Rodolà a écrit :
> You can easily avoid this by setting a lower timeout when calling
> asyncore.loop(), like 1 second or less (for example, Twisted uses 0.001
> secs).
> Actually there's no reason for asyncore to have such a high default
> timeout (30 s
acker.
--- Giampaolo
http://code.google.com/p/pyftpdlib
http://code.google.com/p/psutil
2010/5/6 Paul Moore :
> >From a quick experiment, it seems that select.select with a timeout
> doesn't react to a keyboard interrupt until the timeout expires.
> Specifically, if I do
>
> s = socket
On 6 May, 20:58, Thomas Heller wrote:
> If you look at the source code for time.sleep(), which CAN be interrupted
> by pressing Ctrl-C, you will find that it is carefully programmed to be
> interruptible (sp?). Which is not the case for select.select(), obviously.
Thanks - given this,
Paul Moore schrieb:
>>From a quick experiment, it seems that select.select with a timeout
> doesn't react to a keyboard interrupt until the timeout expires.
> Specifically, if I do
>
> s = socket.socket()
> select.select([s], [], [], 30)
>
> and then press Ctrl-C,
>From a quick experiment, it seems that select.select with a timeout
doesn't react to a keyboard interrupt until the timeout expires.
Specifically, if I do
s = socket.socket()
select.select([s], [], [], 30)
and then press Ctrl-C, Python waits for the 30 seconds before raising
KeyboardI
Bryan Olson wrote:
> There are cases where a socket can select() as readable, but not be
> readable by the time of a following recv() or accept() call. All such
> cases with which I'm familiar call for a non-blocking socket.
I used to believe that if select() said data was ready for reading, a
Bryan Olson wrote:
>
>Where does this come up? Suppose that to take advantage of multi-core
>processors, our server runs as four processes, each with a single thread
>that responds to events via select(). Clients all connect to the same
>server port, so the socket listening on that port is sh
Laszlo Nagy wrote:
[...]
I have read the socket programming howto (
http://docs.python.org/howto/sockets.html#sockets ) but it does not
explain how a blocking socket + select is different from a non blocking
socket + select. Is there any difference?
There is, but it may not effect you. There ar
Can you post an example program that exhibits the behavior you
describe?
I was forgetting about the MSG_WAITALL flag ...
When I started programming with sockets, it was on a platform (IIRC
Solaris) that by default behaved like MSG_WAITALL was set by default
(actually, I don't remember it be
"Francesco Bochicchio" wrote:
> but then, IIRC TCP guarantees that the packet is fully received by
> hand-shaking at transport level between sender and receiver. Ad once the
> packet is fully in the receiver buffer, why should recv choose to give
> back to the application only a piece of it?
T
Saju Pillai ha scritto:
On Dec 31, 7:48 pm, Francesco Bochicchio wrote:
Is this correct ? IIRC even in blocking mode recv() can return with
less bytes than requested, unless the MSG_WAITALL flag is supplied.
Blocking mode only guarantees that recv() will wait for a message if
none is available
Jean-Paul Calderone wrote:
...
On a LAN, it's likely that you'll generally get the exact number of bytes
which the sender passed to one call of send (until the sender starts to
pass really huge strings to send, then it'll get split up) just because
the network has lots of capacity compared to the
On 2008-12-31, Francesco Bochicchio wrote:
> Grant Edwards ha scritto:
>> On 2008-12-30, Francesco Bochicchio wrote:
>>
>>> 3. AFAIK (sorry, I feel acronym-ly today ;), there is no difference in
>>> select between blocking and non-blocking mode. The difference is in the
>>> recv (again, assumin
On Wed, 31 Dec 2008 15:48:50 +0100, Francesco Bochicchio
wrote:
< ... >
Uhm. In my experience, with TCP protocol recv only returned less than
the required bytes if the remote end disconnects. I always check the
What if the sending end actually sent less than you asked for ?
-srp
In blocki
On Wed, Dec 31, 2008 at 5:39 AM, Francesco Bochicchio
wrote:
> Francesco Bochicchio ha scritto:
>
>>
>>> No, in blocking mode it will wait to receive _some_ data (1 or
>>> more bytes). The "requested" amount is strictly an upper
>>> limit: recv won't return more than the requested number of
>>> b
On Dec 31, 7:48 pm, Francesco Bochicchio wrote:
> < ... >
>
> >> Uhm. In my experience, with TCP protocol recv only returned less than
> >> the required bytes if the remote end disconnects. I always check the
>
> > What if the sending end actually sent less than you asked for ?
>
> > -srp
>
> In b
< ... >
Uhm. In my experience, with TCP protocol recv only returned less than
the required bytes if the remote end disconnects. I always check the
What if the sending end actually sent less than you asked for ?
-srp
In blocking mode and with TCP protocol, the recv waits until more bytes
a
On Dec 31, 2:01 pm, Francesco Bochicchio wrote:
> Grant Edwards ha scritto:
>
> > On 2008-12-30, Francesco Bochicchio wrote:
>
> >> 3. AFAIK (sorry, I feel acronym-ly today ;), there is no difference in
> >> select between blocking and non-blocking mode. The difference is in the
> >> recv (again,
Francesco Bochicchio ha scritto:
No, in blocking mode it will wait to receive _some_ data (1 or
more bytes). The "requested" amount is strictly an upper
limit: recv won't return more than the requested number of
bytes, but it might return less.
Uhm. In my experience, with TCP protocol recv o
Jean-Paul Calderone ha scritto:
On Tue, 30 Dec 2008 19:19:08 +0100, Francesco Bochicchio
wrote:
[snip]
If you are interested in socket errors, you should
also fill the third 'fd-set' in the select call, and after select
returns check that fd is not in it anymore:
ready = select.s
Grant Edwards ha scritto:
On 2008-12-30, Francesco Bochicchio wrote:
3. AFAIK (sorry, I feel acronym-ly today ;), there is no difference in
select between blocking and non-blocking mode. The difference is in the
recv (again, assuming that you use TCP as protocol, that is AF_INET,
SOCK_STREAM)
On Tue, 30 Dec 2008 15:55:51 -0500, Jean-Paul Calderone
wrote:
On Tue, 30 Dec 2008 14:41:17 -0600, Grant Edwards wrote:
On 2008-12-30, Francesco Bochicchio wrote:
3. AFAIK (sorry, I feel acronym-ly today ;), there is no difference in
select between blocking and non-blocking mode. The differ
On Tue, 30 Dec 2008 14:41:17 -0600, Grant Edwards wrote:
On 2008-12-30, Francesco Bochicchio wrote:
3. AFAIK (sorry, I feel acronym-ly today ;), there is no difference in
select between blocking and non-blocking mode. The difference is in the
recv (again, assuming that you use TCP as protocol
On 2008-12-30, Francesco Bochicchio wrote:
> 3. AFAIK (sorry, I feel acronym-ly today ;), there is no difference in
> select between blocking and non-blocking mode. The difference is in the
> recv (again, assuming that you use TCP as protocol, that is AF_INET,
> SOCK_STREAM), which in the block
On Tue, 30 Dec 2008 19:19:08 +0100, Francesco Bochicchio
wrote:
[snip]
If you are interested in socket errors, you should
also fill the third 'fd-set' in the select call, and after select returns
check that fd is not in it anymore:
ready = select.select( [fd],[], [fd] )
if fd
sSet():
remaining = size - len(res)
if remaining<=0:
break
# Give one second for an incoming connection so we can stop the
# server in seconds when needed
ready = select.select([fd], [], [], 1)
if fd in ready[0]:
t self.stop_requested.isSet():
>remaining = size - len(res)
>if remaining<=0:
>break
># Give one second for an incoming connection so we can stop the
># server in seconds when needed
>ready
= size - len(res)
if remaining<=0:
break
# Give one second for an incoming connection so we can stop the
# server in seconds when needed
ready = select.select([fd], [], [], 1)
if fd in ready[0]:
data = self.socket
Hi guys,
I have an issue when using select.select(). I have an application that
creates sockets then sends data on them. These sockets are then passed off
to a listener which uses select.select() to detect any responses. For some
reason every socket can only receive one response before my
yes, i missed, sorry
Dennis Lee Bieber wrote:
> On Wed, 26 Oct 2005 11:29:17 +0300, Maksim Kasimov
> <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
>
>
>>you have to use non-block readining.
>>
>>http://docs.python.org/lib/module-select.html:
>>A time-out value of zero specifi
socket, i have stdout.
>
> Any suggestions on how to do a timeout like select.select with stdout?
I am not too familiar with any asynchronous I/O facilities in Python
beyond select, so in your situation I would use the threading module,
with the blocking read in one thread and your time-out i
waiting for more
> bytes. So what I would like is to timeout...and select.selec() seems
> to be what I need. Except I don't have a socket, i have stdout.
>
> Any suggestions on how to do a timeout like select.select with stdout?
>
> Thanks
>
--
Best regards,
Ma
ons on how to do a timeout like select.select with stdout?
Thanks
--
http://mail.python.org/mailman/listinfo/python-list
51 matches
Mail list logo
