Queuing mechanism that is poll/select'able ?

[Aahz Maruch]

In article <txk3df47a6i.fsf at vortex.ukshells.co.uk>,
Chris Ebenezer  <chriseb at pobox.com> wrote:
>aahz at panix.com (Aahz Maruch) writes:
>> 
>> What might well be easier than what you're suggesting is to spawn off
>> threads to handle the external events (sockets); those threads then
>> interact with the standard Queue object(s).
>
>This works if you are only ever going to read from the sockets,  It is
>slightly more complicated than that when you have to write to those
>sockets as well (because writing can block and isn't guarenteed in
>either the non-blocking or blocking scenario - the same as all FD
>based interfaces).   

I don't see what the problem is.  The Queue objects are not affected by
the blocked write, so other threads can still post requests to the
socket thread(s), and they can still retrieve the results of any
previously completed reads or writes.

>If Queue objects could be select'ed on then tehy
>could be used to pass pending output from other threads.   You can't
>do something like (psuedo code):
>
>    if select.select(readfds, writefds, ..... ):
>        ## error handling code
>
>    if able_to_write:
>        nextWrite = Queue.get(noblocking);
>
>Because in the most common case you end up busy waiting in your main
>I/O loop. 

You can't do that directly.  My point is that it's fairly easy to
convert the external activity to Queue-based events.
-- 
                      --- Aahz (Copyright 2000 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het    <*>     http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

Happy second year of the new millennium!