On Sat, Jan 25, 2014 at 1:15 PM, Victor Stinner <[email protected]>
wrote:
> 2014-01-25 Guido van Rossum <[email protected]>:
>> Thanks, Victor. In the end that looks like the best solution.
>
> It looks like Charles-François doesn't like it:
> http://bugs.python.org/issue20311#msg209213
Hm.
> My latest patch is more generic because it uses also the resolution of
> the clock.
That sounds right.
However, now that I see the code, I have a few questions. (Sorry for
shooting first and asking questions later.)
- Is it intentional that granularity is a public attribute of the event
loop? (I can see a use case but also abuses and confusion.)
- Is it intentional that granularity can be *set* by users of the event
loop?
- Personally I would write the code differently -- I would not change the
timeout passed to the selector at all, and when going over the _scheduled
list I would not use ceil() but write it like this:
now = self.time()
while self._scheduled:
handle = self._scheduled[0]
if handle._when > now *+ self.granularity*:
break
handle = heapq.heappop(self._scheduled)
self._ready.append(handle)
ISTM your current code makes the assumption that the timeouts will wake the
process up at "ticks" that can be represented by integer multiples of the
granularity relative to the "zero" of the time source (e.g.
time.monotonic()). While there is probably some kind of tick being
maintained by the OS, I don't know whether this will be correlated to T=0
(the ticks may even drift relative to the clock, depending on how they are
generated by the hardware or OS software).
>> Are there any open issues left in Tulip that you'd like to be handled
>> before CPython beta 3? My first week of classes is over and my Tulip
>> talk is done, so I have a little breathing room this weekend.
>
> Hum, yes, something should be done for subprocess. IMO the API of
> subprocess should be changed. The best would be to provide something
> like StreamReader and StreamWriter for subprocess. If it's not
> possible to develop it before Python 3.4 final, a compromise is to
> ensure that the API allows to develop it later. According to my
> analysis (see the other dedicated thread on Tulip mailing list), it's
> not the case with the current API.
It's clear that not enough people have actually tried to *use* the
subprocess API. :-(
My suggestion: first try to write code using the existing public API to
hook up the existing StreamReader / StreamWriter classes to stdin, stdout,
stderr of a subprocess. Then decide whether it makes sense to add such code
as a new, "simpler" API to streams.py or to publish it as an example
somewhere. StreamReader and StreamWriter are explicitly intended to be
hooked up in other ways than the code in open_connection(), start_server()
and StreamReaderProtocol), and those three are intended to be simple enough
to be able to be copied into user code and then modified for the user's
purpose. If changes to StreamReader/Writer are necessary we should
prioritize those -- their implementation is *not* meant to be copied.
> You may take a look at my two following issues, but they are minor.
> http://code.google.com/p/tulip/issues/detail?id=110
This already seems checked in. What's left?
> http://code.google.com/p/tulip/issues/detail?id=112
Uninteresting, can always be done later.
>
> This bug looks more important:
> http://code.google.com/p/tulip/issues/detail?id=109
If you can review this and decide whether it can be applied I would be
grateful. (The patch author is the FastChildWatcher author so I kind of
trust him implicitly.)
> It tries to fix all remaing issues before beta3.
>
> Victor
--
--Guido van Rossum (python.org/~guido)
