[gst-devel] blocking vs. non-blocking io in elements ?

[David Schleef]

On Mon, Apr 26, 2004 at 01:15:49PM +0200, Thomas Vander Stichele wrote:
> Hi,
> 
> While testing/writing pipe support in file*, I noticed we do all our I/O
> in elements in blocking mode.  For normal files this isn't much of an
> issue; for other files (pipes, sockets) this might be a problem,
> though.  It causes elements to block in their state_change functions.  I
> don't know if we have a policy for that ? Should we prefer blocking
> mode, or use non-blocking mode in these cases ? If we do, how should it
> work ? Maybe this was documented somewhere at some point, but  I didn't
> find anything relevant, and I'd prefer some general policy so that the
> tcp elements don't have to be too different from fdsrc/filesrc ones.

filesrc/sink is not appropriate for reading/writing anything except
real files.  The fdsrc/fdsink model would be better for reading
and writing streams.  For now, I'd suggest adding a timeout
property and signal to filesrc, although I think it makes more sense
in the long run for the signal to just be an element error.

In general, Benjamin and I have decided that we want to move to an
element model where element code _never_ blocks.  Once that is
accomplished, we will have the ability for a much higher-level
view of timeouts and such.



dave...