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

Tim Peters tim.one@home.com
Mon, 6 Aug 2001 01:17:15 -0400

[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 .