[Urwid] MainLoop's pipe is not removed after pipe data ends.

Andrew Wu andrewwu.tw at gmail.com
Thu Apr 12 09:19:26 EDT 2012


Ian Ward <ian at excess.org> 於 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.excess.org/pipermail/urwid/attachments/20120412/62b46c05/attachment.htm 


More information about the Urwid mailing list