"Terry Reedy" <t...@udel.edu> wrote:
> If I understand correctly, your problem and solution was this:
>
> You have multiple threads within a long running process. One thread
> repeatedly reads a socket.
Yes and it puts what it finds on a queue. - it is a pre defined simple comma
delimited record.
> You wanted to be able to occasionally send
> an object to that thread.
Close - to another thread that reads the queue, actually.
> Rather than rewrite the thread to also poll a
> queue.Queue(), which for CPython sends objects by sending a pointer,
It is in fact reading a queue, and what it gets out in the vast majority of
cases is the record that came from the socket.
>you
> converted pointers to strings and sent (multiplex) them via the text
> stream the thread was already reading -- and modified the thread to
> decode and act on the new type of message.
Basically yes - the newly created thread just puts a special text string
onto the queue. As I pointed out in my reply to Skip, this makes the
unpacking at the output of the queue standard, just using split(','),
and it is this simplicity that I wanted to preserve, as it happens almost
all of the time.
> And you are willing to share the can code with someone who has a similar
> rare need and understands the danger of interpreting ints as addresses.
> Correct?
Absolutely right on - I do not think that it is the kind of thing that should
be in the std lib, except as a kind of Hara Kiri bomb -
uncan(a random number string), and die!
It would also help if someone who is more knowledgable about python
would have a look at the C code to make it more robust.
There are only 2 routines that matter - it is about a screenfull.
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
