Ian Ward <[email protected]> 於 2012年4月11日上午3:03 寫道：
> Now it seems like there shouldn't be a special way to close a pipe
> with a handler's return value (getting too complicated)
>
> Thoughts?
>
Yes, this is my idea:
==
--- urwid_bak/main_loop.py 2012-04-03 19:20:16.000000000 +0800
+++ urwid/main_loop.py 2012-04-12 20:44:11.000000000 +0800
@@ -184,10 +184,9 @@
def cb():
data = os.read(pipe_rd, PIPE_BUFFER_READ_SIZE)
- rval = callback(data)
- if rval is False:
- self.event_loop.remove_watch_file(watch_handle)
- os.close(pipe_rd)
+ callback(data)
+ if data == "":
+ self.remove_watch_pipe(pipe_wr)
watch_handle = self.event_loop.watch_file(pipe_rd, cb)
self._watch_pipes[pipe_wr] = (watch_handle, pipe_rd)
==
The client code gets writer_fd from watch_pipe. The client code is always
responsible for closing writer_fd.
If MainLoop object detected the pipe reached EOF(an empty string is read,
which means writer_fd is closed, and no more data left in the pipe), it
calls remove_watch_pipe to closes reader_fd and does the cleanup.
The client code can also call remove_watch_pipe by itself, but in this
case, the client code still need to close writer_fd.
The callback function doesn't need to return any value. I think this
interface may be more understandable?
Or, the MainLoop may use Queue to communicate with other threads, by adding
methods like watch_queue and remove_watch_queue. In this case, we don't
have to worry about leaking fds, and data in Queues is easier to be
processed than in pipes.
_______________________________________________
Urwid mailing list
[email protected]
http://lists.excess.org/mailman/listinfo/urwid
