[Python-ideas] Tulip / PEP 3156 - subprocess events

[Guido van Rossum]

On Fri, Jan 18, 2013 at 2:32 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 18 January 2013 21:24, Guido van Rossum <guido at python.org> wrote:
>>> To create that create_corba_connection() function, you'd be expected
>>> to subclass the standard event loop, is that right?
>>
>> No, it doesn't need to be a method on the event loop at all. It can
>> just be a function in a different package; it can use
>> events.get_current_event_loop() to reference the event loop.
>
> Aargh. I'm confused again! (I did warn you about dumb questions, didn't I? :-))
>
> The event loop implementation contains the code that does the OS-level
> poll for events to process. (In tulip, that is handled by the selector
> object, but that's not mentioned in the PEP so I assume it should be
> considered an implementation detail). So, the event loop has to define
> what types of (OS-level) objects can be registered. At the moment,
> event loops only handle sockets (via select/poll/etc) and even the raw
> add_reader methods are not for end user use.

Well, *on UNIX* the event loop also handles other file descriptors,
and there's nothing to actually *prevent* an end user using
add_reader. It just may not work when their code is run on Windows,
but then it probably won't run on Windows anyway. :-)

> So a standalone create_corba_connection function can certainly get the
> event loop using get_current_event_loop(), but it has no means of
> asking the event loop to poll the CORBA connection it creates for new
> messages.

Right, unless it is in on the conspiracy between the event loop and
the selector (IOW if it is effectively aware and/or part of the event
loop implementation for the specific platform).

> Without direct access to the selector (or equivalent) it
> can't add the extra event source. (Unless that source is a pollable
> file descriptor and it's willing to play with the optional add_reader
> methods, but that's not a "new event source" then...) The same problem
> will likely occur if you try to integrate Windows GUI events (you
> check for a GUI message by calling a Windows API).

Let's say that you are thinking through the example much farther than
I had intended... :-)

> I don't think this matters except in obscure cases (it's likely a huge
> case of YAGNI) but I genuinely don't understand how you can say that
> create_corba_connection() could be written as a standalone function,
> and yet that create_connection() has to be a method of the event loop.
> That's what I'm getting at when I keep saying that I see you treating
> sockets as "special". There's clearly something I'm missing in your
> thinking, and it keeps tripping me up.

Let's assume that create_corba_connection() actually *can* be written
using add_reader(), but only on UNIX. So the app is limited to UNIX,
and in that context create_corba_connection() can be a function in
another package.

It's not so much that create_connection() *must* be a method on the
event loop. It's just that I *want* it to be a method on the event
loop so you will be able to write user code that is portable between
UNIX and Windows. It will call create_connection(), which is a
portable API with two platform-specific implementations; on Windows
(when using IOCP) it will return an instance of, say,
_IocpSocketTransport(), while on UNIX it returns a
_UnixSocketTransport() instance.

But we have no hope of making create_corba_connection() on Windows (in
my example -- please just play along) and hence there is no need to
make it a method of the event loop.

-- 
--Guido van Rossum (python.org/~guido)