[gst-devel] blocking vs. non-blocking io in elements ?
ds at schleef.org
Mon Apr 26 12:46:05 CEST 2004
On Mon, Apr 26, 2004 at 01:15:49PM +0200, Thomas Vander Stichele wrote:
> 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.
More information about the gstreamer-devel