Jason Lunz wrote:
> I imagine if one were going to do this, that would be hidden in the
> stdlib.
Having it in libc would be okay. The important thing
is that the implementation should allow your handlers
to get called even if some library call is blocked
and not being cooperative.
--
Greg
_
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote:
> tomer filiba <[EMAIL PROTECTED]> wrote:
>
> >> You can use WSAAsyncSelect to activate message notification for
> >> socket events, and then wait with MsgWaitForMultipleObjects.
> >
> > i remember reading in the winsock manual that these two methods are
tomer filiba <[EMAIL PROTECTED]> wrote:
>> You can use WSAAsyncSelect to activate message notification for
>> socket events, and then wait with MsgWaitForMultipleObjects.
>
> i remember reading in the winsock manual that these two methods are
> slower, and not suitable for servers.
Might be FUD o
> You can use WSAAsyncSelect to activate message notification for socket events,
> and then wait with MsgWaitForMultipleObjects.
i remember reading in the winsock manual that these two methods are slower,
and not suitable for servers.
> It *is* possible to have a single point of event dispatching
> On 6/6/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>> tomer filiba <[EMAIL PROTECTED]> wrote:
>>
One thing I would like to raise is the issue of KeyboardInterrupt.
I find very inconvenient that a normal application doing a very
simple blocking read from a socket can't be interrupt
WaitForMultipleObjects doesnt work on sockets of files...
On 6/6/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> tomer filiba <[EMAIL PROTECTED]> wrote:
>
> >> One thing I would like to raise is the issue of KeyboardInterrupt. I
> >> find very inconvenient that a normal application doing a very sim
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Ronald Oussoren wrote:
>
> > I'm slighly worried about this thread. Async I/O and "read exactly N
> > bytes" don't really match up. I don't know about the other mechanisms,
> > but at least with select and poll when the system says you can read
> >
On Wed, Jun 07, 2006 at 01:20:02AM +1200, Greg Ewing wrote:
> It's not quite the same thing, anyway. What I had in mind was
> attaching the handler itself directly to the file descriptor, rather
> than going through a signal number. That way, different piece of code
> can use the mechanism independ
Marcin 'Qrczak' Kowalczyk wrote:
> Greg Ewing <[EMAIL PROTECTED]> writes:
>> f.read(0, num_bytes) # current read() behaviour
>
> Current read() reads at least 1 byte.
Except if EOF is reached before getting any bytes.
In that case, if min_bytes is 0, the call simply
returns 0 bytes.
Ronald Oussoren wrote:
> I'm slighly worried about this thread. Async I/O and "read exactly N
> bytes" don't really match up. I don't know about the other mechanisms,
> but at least with select and poll when the system says you can read
> from a file descriptor you're only guaranteed that on
Jason Lunz wrote:
> [EMAIL PROTECTED] said:
>
> > Sort of like being able to define signal handlers
> > for file descriptors instead of having a small, fixed number of
> > signals.)
>
> That's supported on linux, but I don't
> know how portable it is. See F_SETSIG in fcntl(2), and sigaction(2).
Greg Ewing <[EMAIL PROTECTED]> writes:
> The two variations we're considering would then be special
> cases of this:
>
>f.read(0, num_bytes) # current read() behaviour
>
>f.read(num_bytes, num_bytes) # record-oriented read() behaviour
Current read() reads at least 1 byte.
--
On 6-jun-2006, at 11:51, Nick Coghlan wrote:
> Greg Ewing wrote:
>> tomer filiba wrote:
>>
>>> okay, i give up on read(n) returning n bytes.
>>
>> An idea I had about this some time ago was that read()
>> could be callable with two arguments:
>>
>>f.read(min_bytes, max_bytes)
>>
>> The two va
Greg Ewing wrote:
> tomer filiba wrote:
>
>> yes, but +=/-= can be overriden to provide "efficient seeking". and, just
>> thought about it: just like negative indexes of sequences, negative positions
>> should be relative to the end of the stream. for example:
>>
>> f.position = 4 # absolute -
Greg Ewing wrote:
> tomer filiba wrote:
>
>> okay, i give up on read(n) returning n bytes.
>
> An idea I had about this some time ago was that read()
> could be callable with two arguments:
>
>f.read(min_bytes, max_bytes)
>
> The two variations we're considering would then be special
> case
tomer filiba <[EMAIL PROTECTED]> wrote:
>> One thing I would like to raise is the issue of KeyboardInterrupt. I
>> find very inconvenient that a normal application doing a very simple
>> blocking read from a socket can't be interrupted by a CTRL+C
>> sequence. Usually, what I do is to setup a time
[EMAIL PROTECTED] said:
> (BTW, I actually think this sort of functionality should be part of
> the OS kernel, with event-driven programs and libraries being so
> important nowadays. Sort of like being able to define signal handlers
> for file descriptors instead of having a small, fixed number of
tomer filiba wrote:
> yes, but +=/-= can be overriden to provide "efficient seeking". and, just
> thought about it: just like negative indexes of sequences, negative positions
> should be relative to the end of the stream. for example:
>
> f.position = 4 # absolute -- seek(4, "start")
> f.pos
tomer filiba wrote:
> okay, i give up on read(n) returning n bytes.
An idea I had about this some time ago was that read()
could be callable with two arguments:
f.read(min_bytes, max_bytes)
The two variations we're considering would then be special
cases of this:
f.read(0, num_bytes)
tomer filiba wrote:
> I wrote:
> > My current opinion on select-like functionality is
> > that you shouldn't need to import a module for it at
> > all. Rather, you should be able to attach a callback
> > directly to a stream. Then there just needs to be
> > a wait_for_something_to_happen() fun
> I don't believe it would "[destroy] the very foundations of python"
> (unicode is not the very foundation of Python, and it wouldn't destroy
> unicode, only change its comparison semantics), but I do believe it
> "[lacks] a proper rationale"
no, it would break the basic rules of comparisson. all
hey
> One thing I would like to raise is the issue of KeyboardInterrupt. I find
> very inconvenient that a normal application doing a very simple blocking
> read from a socket can't be interrupted by a CTRL+C sequence. Usually, what
> I do is to setup a timeout on the sockets (eg. 0.4 seconds) and
"tomer filiba" <[EMAIL PROTECTED]> wrote:
>
> > > well, it's too hard to design for a nonexisting module. select is all
> > > there
> > > is that's platform independent.
> >
> > It is /relatively/ platform independent.
>
> if it runs on windows, linux, *bsd, solaris, it's virtually platform
> i
tomer filiba wrote:
> some time ago i wrote this huge post about stackable IO and the
> need for a new socket module. i've made some progress with
> those, and i'd like to receive feedback.
>
> * a working alpha version of the new socket module (sock2) is
> available for testing and tweaking with
> > well, it's too hard to design for a nonexisting module. select is all there
> > is that's platform independent.
>
> It is /relatively/ platform independent.
if it runs on windows, linux, *bsd, solaris, it's virtually platform
independent.
i don't consider the nokia N60 or whatever the name was
> I'm -1 on having multiple kinds of read methods which> are available only on some kinds of streams. The> basic interface of a stream should be dirt simple.
it's a convenience method. instead of doing it yourself everytime,readavail() returns all the available data in the socket's buffers.the basi
tomer filiba wrote:
> NetworkStreams have a readavail() method, which reads all the available
> in-queue data, as well as a may_read and a may_write properties
I'm -1 on having multiple kinds of read methods which
are available only on some kinds of streams. The
basic interface of a stream should
Nick Coghlan <[EMAIL PROTECTED]> wrote:
[snip]
> Any operations that may touch the filesystem or network shouldn't be
> properties - attribute access should never raise IOError (this is a guideline
> that came out of the Path discussion). (e.g. the 'position' property is
> probably a bad idea,
"tomer filiba" <[EMAIL PROTECTED]> wrote:
[snip]
> > - interaction with (replacement of?) the select module
>
> well, it's too hard to design for a nonexisting module. select is all there
> is that's platform independent.
It is /relatively/ platform independent.
> random idea:
> * select is vir
you certainly have good points there.
i'll start with the easy ones:
>Some things that don't appear to have been considered in the iostack
design yet:
> - non-blocking IO and timeouts (e.g. on NetworkStreams)
NetworkStreams have a readavail() method, which reads all the available
in-queue data, a
tomer filiba wrote:
> hi all
>
> some time ago i wrote this huge post about stackable IO and the
> need for a new socket module. i've made some progress with
> those, and i'd like to receive feedback.
>
> * a working alpha version of the new socket module (sock2) is
> available for testing and tw
hi all
some time ago i wrote this huge post about stackable IO and the
need for a new socket module. i've made some progress with
those, and i'd like to receive feedback.
* a working alpha version of the new socket module (sock2) is
available for testing and tweaking with at
http://sebulba.wikisp
32 matches
Mail list logo
