search

k0zmo / live555

Live555 repository with epoll scheduler
GNU Lesser General Public License v3.0
18 stars 10 forks source link

EpollTaskScheduler does not send data #1

Open ksotik opened 7 years ago

ksotik commented 7 years ago

Hello! I tried to test your code on the server (the standard live555MediaServer example server), explicitly the use of EpollTaskScheduler.The connection is set correctly, and the server responds correctly to the RTSP requests, but does not start sending data (not RTP or RAW UDP both). This is not yet finalized, or am I doing something wrong?

ksotik commented 7 years ago

After studying the code, I came to the conclusion that the problem is in calling epoll_ctl on the file descriptor at the time the read task occurred from the file. Therefore, when reading from a file, events do not fire and the server does not send data. I'm looking for a way to get around this.

ksotik commented 7 years ago

So this is because epoll does not support regular files.

k0zmo commented 7 years ago

Sorry for the delay.

I understand we're talking about Linux here. If so, that's correct - epoll does not support non-blocking IO on regular files - so much for "everything is a file". You should get EPERM on call to epoll_ctl() with such descriptor.

However, select() is no better. It "works" only at first glance - each call will return immediately with descriptor readable/writeable status. With vanilla live555's TaskScheduler you are basically performing synchronous I/O, just from within the select() reactor.

Different story for Windows though. You can get full asynchronous I/O both on sockets and files but you need to harness the power of IOCP - which in the case of live555 library is close to impossible with no fundamental changes (a switch from Reactor pattern to Proactor pattern).

For a quick fix check InputFile.hh:34, specifically author's comment on I/O in Windows OS (with FUD comments on Windows capabilities regarding asynchronous I/O).

You shouldn't lose any performance with that change (-DREAD_FROM_FILES_SYNCHRONOUSLY) since you already perform blocking I/O, just masked behind the reactor which in this case doesn't do any good in terms of performance.