[Python-Dev] FW: [Python-Help] Python threads with suncc (Forte 6.1) compiler

[Tim Peters]

[Guido, on Tim's select() thought-algorithm]
> That looks like a good way to avoid the double fileno() calls.
> Drawback: the implementation you sketched seems to create a twople per
> file descriptor.  That's not quite a malloc (twoples are cached), but
> still.
>
> If someone feels like implementing this, please go ahead!

Yes, it does create twoples (as I said in my original msg).

That can also be avoided:  allocate result lists initially each the same
size as its corresponding input list.  Store just fds in the slots.  The
twoples are now implicit, in parallel lists (reusing the input lists as-is
to continue storing the objects).

The sole reason this can't work now is that a fileno() call may reach back
in and mutate one of the input lists -- that's the only thing creating
explicit twoples "off to the side" is guarding against, and the only real
reason I can see for why the current code is allocating giant pylist
thingies and storing "redundant" pointers to the objects in them.

So play the same trick list.sort plays:  redirect the input lists' type
pointers to the immutable list object for the duration of select().  It's
really no feature that select() can return ill-defined results if a fileno()
method mutates the list!  I'd rather the language raise an exception if
anyone *tries* to mutate an input list for the duration -- it's never a
reasonable thing for a fileno() method to do.

Then again, I was always the immutable-list trick's biggest fan <wink>.