id,summary,reporter,owner,description,type,status,priority,milestone,component,resolution,keywords,cc,branch,branch_author,launchpad_bug
3983,"asynchronous, non-blocking file I/O",glyph,,"Twisted should have an official API for (at least notionally) non-blocking filesystem input and output.

This may not be possible without cheating a little bit, because [http://stackoverflow.com/questions/87892/what-is-the-status-of-posix-asynchronous-i-o-aio asynchronous file I/O support is not really there in most operating systems].  However, we could:

  1. do the file I/O in a subprocess
  1. do the file I/O in a thread (one thread per mount point?  a threadpool?)
  1. just block, with timers, but present an API which would be amenable to non-blocking later.  (Possibly, this strategy is already partially satisfied by `twisted.protocols.basic.FileSender`.)
  1. some combination of these, with a back-end that could be selected somehow

Something that `FileSender` does not satisfy is some equivalent to 'tail -f'; allowing a Twisted program to easily and non-blockingly monitor the log or file output of another program as if it were coming from a socket.  This is somewhat tricky to do in the general case, since it's hard to detect when the log or file is done being written.  Still there are heuristics (wait until this process has died, wait until this other file has disappeared) which could provide a useful substitute for certainty of connectionLost.

(I will be surprised if this is not a duplicate of something, but searches yield nothing.)",enhancement,new,low,,core,,,jason.heeris@… yac@… jamesbroadhead@… tobias.oberstein@…,,,