[FFmpeg-devel] [PATCH] Introduce flags for non-blocking protocols

Nicolas George nicolas.george
Wed Jan 12 22:35:48 CET 2011


Le tridi 23 niv?se, an CCXIX, Nicolas George a ?crit?:
> +/**
> + * Do not block while opening/connecting the context.
> + * If this flag is set, the opening operation of the context will return
> + * immediately instead of blocking.
> + * If the operation is currently being processed by the system (e.g.
> + * establishing a connection on a slow network), url_connect returns
> + * AVERROR(EINPROGRESS), and the application is supposed to call url_connect
> + * again to check for completion.
> + * If the operation is not possible for any other reason (e.g. a device
> + * currently in use by another process), another error is returned.
> + * If this flag is not set, url_open/url_connect will never return
> + * AVERROR(EINPROGRESS).
> + * This flag is cleared from the flags field in URLContext once the
> + * connection has been established.
> + * Warning: non-blocking protocols is work-in-progress; this flag may be
> + * silently ignored.
> + */
> +#define URL_FLAG_OPEN_NONBLOCK 8

After further thought, I's like to withdraw that part. Doing TCP handshake
in background and not blocking endlessly on /dev/dsp are two completely
different things; for example in ffmpeg we want the second but not the
first.

Thus, I amend my proposal:

- URL_FLAG_NONBLOCK as proposed.

- Network connects are always blocking, just as now, until someone makes a
  proposal for a good API to do them in background. It would require
  background DNS too. Good luck.

- Device opens should always return EBUSY immediately and not block forever.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110112/72477751/attachment.pgp>



More information about the ffmpeg-devel mailing list