1149313 - Remove main-thread blocking operations from NS_OpenAnonymousTemporaryFile

Status: NEW

(Core :: XPCOM, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Currently, NS_OpenAnonymousTemporaryFile does potentially blocking I/O by opening a file.  The out-of-process case is worse: it also uses sync IPC from the child to the parent, thus blocking both main threads and the original caller (if off-main).

Improving this situation will require making NS_OpenAnonymousTemporaryFile an async interface and adapting its callers accordingly; this allows using async IPC and blocking fewer threads in the out-of-process case.  Ideally, the actual file opening would then be moved to some non-main thread (maybe via the StreamTransportService?).

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

It's looking like the future of desktop sandboxing will involve a temporary directory that can be written to “directly” (which might be implemented internally by interception and brokering, depending on platform, but would seem like the normal way of opening a file to the calling code).  In that case, NS_OpenAnonymousTemporaryFile could just open the file normally in the content process, and that would avoid blocking anything's main thread.

Comment 2

[Jens Stutte [:jstutte]]

There has been some change here in bug 1346987. Is this bug obsolete then?

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Current status seems to be that the sync IPC is gone, and there's a debug assertion that the function is used only in the parent process; there's still potentially main-thread I/O, and that may or may not be worth fixing, but in any case it doesn't make sense for this to be in the DOM Content Processes component. Maybe XPCOM, because that's where the code lives.