On Thu, 29. Aug 02:28, Marton Balint wrote: > > > On Wed, 28 Aug 2019, Andriy Gelman wrote: > > > > > > + h->is_streamed = 1; > > > > > + > > > > > + av_strstart(uri, "zmq:", &uri); > > > > > + > > > > > + /*publish during write*/ > > > > > + if (h->flags & AVIO_FLAG_WRITE) { > > > > > + s->socket = zmq_socket(s->context, ZMQ_PUB); > > > > > + if (!s->socket) { > > > > > + av_log(h, AV_LOG_ERROR, "Error occured during > > > > > zmq_socket(): %s\n", zmq_strerror(errno)); > > > > > > zmq_errno() instead of errno? Same goes for all similar cases. > > > > The documentation says to use zmq_errno() on non-POSIX systems. But also > > suggests: > > "Users not experiencing issues with retrieving the correct value of errno > > should > > not use this function and should instead access the errno variable > > directly." > > > > On IRC J_Darnley pointed out that ffmpeg.c includes errno.h without any > > checks. > > It seems reasonable to assume that errno is available. > > That does not matter, because ffmpeg uses errno for checking errors when > ffmpeg.c calls the standard C library, not when a linked library calls the > standard C library. > > I am no expert in this area, but as far as I understood it from the docs of > zmq_errno() the problem is not the "availability" of errno but that multiple > C runtimes might be in use an you might not get the errno of the C runtime > libzmq is using but the errno of the C runtime your application is using. > > Here are some more deails I found: > https://grokbase.com/t/zeromq/zeromq-dev/1087reyava/portability-of-0mq-api > > So zmq_errno() still feels safer and more portable.
ok, I misunderstood the problem. I'll use zmq_errno() > > > > > > +static int ff_zmq_write(URLContext *h, const unsigned char *buf, int > > > > > size) > > > > > +{ > > > > > + int ret; > > > > > + ZMQContext *s = h->priv_data; > > > > > + > > > > > + ret = zmq_send(s->socket, buf, size, ZMQ_DONTWAIT); > > > > > > I can see that you are using non-blocking mode. A polling with timeout > > > approach is preferred, see how tcp or unix does it. > > > > I used polling in the initial patch, but I switched to non-blocking because > > I > > thought it was a cleaner solution. I'll revert to polling with a timeout in > > the > > next version. > > Polling returns immediately when data is available. For the non-blocking > approach the code falls back to 1ms (which can easily be 10ms on Win32) > sleeps after a few retries. This severely can hurt performance, that is why > the polling approach is preferred. That's very good to know. Thanks, Andriy _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".