Miklos Szeredi wrote:Yeap, spurious notifications don't cause any problems. poll/select/epoll can poll on massive number of files. I don't think it's wise to have that many outstanding requests. FUSE currently uses linear list to match replies to requests and libfuse will consume one thread per each poll if implemented like other requests. It can be made asynchronous from libfuse tho. I kind of like the original implementation tho. The f_ops->poll interface is designed to be used like ->poll returning events if available immediately and queue for later notification as necessary. Notification is asynchronous and can be spurious (this actually comes pretty handy for low level implementation). When notified, upper layer queries the same way using ->poll. This is quite convenient for low level implementation as the actual logic of poll can live in ->poll proper while notifications can be scattered around places where events can occur. Thanks. -- tejun --
| Avi Kivity | [PATCH 09/58] KVM: MMU: Respect nonpae pagetable quadrant when zapping ptes |
| Andrew Morton | 2.6.25-rc2-mm1 |
| James Morris | Re: LSM conversion to static interface |
| Eric W. Biederman | Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu |
git: | |
| David Miller | Re: 2.6.25-rc8: FTP transfer errors |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [GIT *] Solos PCI ADSL card update |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
