Closed
Bug 709736
Opened 13 years ago
Closed 12 years ago
[OS.File] investigate OS-accelerated asynchronous back-ends
Categories
(Core :: Networking: File, enhancement)
Core
Networking: File
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: Yoric, Unassigned)
References
Details
For the moment, JSFileAPI asynchronous IO is either main-thread IO cut in chunks or off-main thread synchronous IO.
We should investigate using AIO/epoll/iocp/libev/libevent to optimize this.
Reporter | ||
Comment 1•13 years ago
|
||
- libev, libevent, kqueue, epoll cannot handle regular files;
- from what I understand, AIO (under Linux) and IOCP (under Windows) can;
- on the Mac, from what I understand, the only solution is dispatching to another thread.
I believe that we should first implement dispatching to another thread, and then investigate AIO and IOCP.
Depends on: OS.File
Reporter | ||
Updated•12 years ago
|
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
Summary: Efficient JS File API - investigate OS-accelerated asynchronous back-ends → [OS.File] investigate OS-accelerated asynchronous back-ends
Comment 2•12 years ago
|
||
Probably stating the obvious here, but the stream transport service (nsIStreamTransportService) already converts synchronous blocking I/O to asynchronous non-blocking I/O via a pool of background threads.
Reporter | ||
Comment 3•12 years ago
|
||
Sure. However, this bug is about whether we can do better than a background thread for specific I/O tasks. I am not too confident that we can, though.
Reporter | ||
Comment 4•12 years ago
|
||
This bug is probably not very useful after all.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•