[FFmpeg-devel] [PATCH 1/2] lavu: add thread message API.

[Nicolas George]

Le duodi 2 floréal, an CCXXII, Lukasz Marek a écrit :
> hmm, Isn't it a maximum number of elements?

Fixed.

> You can add that thread will be blocked or AVERROR(EAGIAN) will be
> returned depending on flag when queue is full. Here or at send doxy.

The doxy for AV_THREAD_MESSAGE_NONBLOCK already says it. Do you believe it
needs to be repeated? It seems pretty obvious to me.

> This function is not thread-safe. Second thread may be in the middle
> of sending/receiving a message. In such API it seems to be serious.

Added a caveat in the documentation. The program should free the message
queue once it is fully no longer in use. Something like that:

    ret = av_thread_message_queue_recv(mq, msg, 0);
    if (ret == AVERROR_EOF) {
	av_thread_message_queue_free(&mq);
	return;
    }

or:

    av_thread_message_queue_set_err_recv(mq, AVERROR_EOF);
    pthread_join(other_thread);
    av_thread_message_queue_free(&mq);

> It would be nice to have also timeout, but I see w32threads are
> missing pthread_cond_timedwait()

I consider programs that need a timeout in this kind of place to be
misdesigned. They usually mean that the program is waking up regularly to
check for other things: useless wake ups (power consumption) when nothing
happened and latency when something happens.

I suppose there would be some legitimate cases for timeouts, but in the
general case, I consider it best if all wake-ups causes are aggregated into
the single message queue. In other words, if you need a timeout, arrange for
another thread to send some kind of MESSAGE_TYPE_TIMEOUT at the appropriate
time.

In fact, I believe even the non-blocking variant is evil, but I can imagine
immediate non-blocking to be necessary in some cases. (And also, the current
ffmpeg.c code requires it.)

> There is no way to get notified there is a message in the queue for
> receiving thread. It has to poll or get blocked. Maybe add a
> callback for it?

I am pretty sure there is no way of preempting another thread to make it
execute a callback. (Well, there would be signals, but mixing signals with
threads is a sure way of messing everything up.)

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140421/e732913d/attachment.asc>