3 ms·

I'd contend the opposite, polling is better for dynamic content. Let's say you have 1000 requests for a landing page, and the landing page has a data request t

I'd contend the opposite, polling is better for dynamic content. Let's say you have 1000 requests for a landing page, and the landing page has a data request that scrapes the entire database to find the popular-maximum-geo-similarity-reccomendation-zone-geo-user-thing list for the entire site, but only updates once every 10 seconds. Ideally, you want to only send at most 1 request to your database every 10 seconds, without having to open a new connection. If you are doing a polling server and have all 1000 clients waiting for the data, you can trigger a callback to all of them when the database reports back without having to recopy data, use shared memory, do more ipc, or context switches. And for the 1000 clients to pause to wait for that single combined data callback, no extra blocking reads\connections to anything were necessary. If by static content you are referring to file transfers, polling does not actually work on regular files in Linux. I believe they will always return ready to read even if reading would block. So usually a thread or forked process is actually required when handling files unless you dont mind disk seeks pausing the entire event loop on your server.

rcoder 15y ago
At the risk of feeding the trolls, I couldn't help weighing in here... First of all: you're just straight-up wrong about file transfers and polling. The select(), epoll(), et. al. syscalls are exactly what you want for large network file transfers. This is not the same as naive "polling", but is what most implementers mean when they talk about an event/polling based server implementations. Even "green" threading runtimes like MRI and CPython can still multiplex threads in the presence of blocking I/O calls, because the standard C syscalls can easily indicate when the main thread would block while trying to read or write. Furthermore, a "threaded" server in no way has to allocate a full hardware thread for every client. Single-threaded, callback-based systems may fare nearly as well for I/O-bound workloads, but threads still have real value for many if not most real-world concurrent systems. A pool of worker threads can keep both the CPU and I/O subsystems maximally active without forcing a "shared nothing" architecture onto a system located on a single physical host. In a world of multicore CPUs, limited L1/L2 cache, and fast kernel schedulers, threaded code can stand toe-to-toe with pure event loops for non-trivial workloads.
- davidhollander 15y ago
  >you're just straight-up wrong about file transfers and polling. The select(), epoll(), et. al. syscalls are exactly what you want for large network file transfers. I think there's some confusion on your end. My assertion was not that you shouldn't use polling for file transfers, but that you also needs to use at least one additional fork\ thread to do the polling in a second event loop to isolate disk-dependent connections, because polling does not work on the disk part of a file transfer, only the network part. > standard C syscalls can easily indicate when the main thread would block while trying to read or write Only on the socket end. Not the regular-file end. This has been the case for a long time on linux with O_NONBLOCK and regular files (aka not pipes\sockets\processes). Which OS\kernel version are you using?

rcoder 15y ago

At the risk of feeding the trolls, I couldn't help weighing in here... First of all: you're just straight-up wrong about file transfers and polling. The select(), epoll(), et. al. syscalls are exactly what you want for large network file transfers. This is not the same as naive "polling", but is what most implementers mean when they talk about an event/polling based server implementations. Even "green" threading runtimes like MRI and CPython can still multiplex threads in the presence of blocking I/O calls, because the standard C syscalls can easily indicate when the main thread would block while trying to read or write. Furthermore, a "threaded" server in no way has to allocate a full hardware thread for every client. Single-threaded, callback-based systems may fare nearly as well for I/O-bound workloads, but threads still have real value for many if not most real-world concurrent systems. A pool of worker threads can keep both the CPU and I/O subsystems maximally active without forcing a "shared nothing" architecture onto a system located on a single physical host. In a world of multicore CPUs, limited L1/L2 cache, and fast kernel schedulers, threaded code can stand toe-to-toe with pure event loops for non-trivial workloads.

davidhollander 15y ago
>you're just straight-up wrong about file transfers and polling. The select(), epoll(), et. al. syscalls are exactly what you want for large network file transfers. I think there's some confusion on your end. My assertion was not that you shouldn't use polling for file transfers, but that you also needs to use at least one additional fork\ thread to do the polling in a second event loop to isolate disk-dependent connections, because polling does not work on the disk part of a file transfer, only the network part. > standard C syscalls can easily indicate when the main thread would block while trying to read or write Only on the socket end. Not the regular-file end. This has been the case for a long time on linux with O_NONBLOCK and regular files (aka not pipes\sockets\processes). Which OS\kernel version are you using?