Closed Bug 678369 Opened 13 years ago Closed 2 years ago

remove usage of PR_CreateProcess from nsIProcess (for unix at least)

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1406971

People

(Reporter: karlt, Unassigned)

References

(Depends on 1 open bug)

Details

On Unix, PR_CreateProcess has the problems discussed in bug 227246 and bug 147659. This simplest solution would seem to be to replace NSPR function with POSIX functions on such systems.
Blocks: 678372
Bug 600711 changed the nsIProcess implementation for Mac to use posix_spawnp. That would help with bug 227246 but not bug 147659. If posix_spawn_file_actions_addclose were used, all OPEN_MAX fds would have to be provided because new fds may be opened by other threads before the fork. An implementation that closed after the fork, or used a glib method to do similar would be tidier.
Blocks: 705543
Blocks: 847558
Blocks: 933680
is this a hard bug to fix? I want to know if we should wait for this or disable the test case from bug 933680 temporarily.
I don't know of anyone actively working on this, so I wouldn't wait for this.
Depends on: 1406971

Bug 1406971 took care of this on Unix, and we're already using other APIs on Windows and Mac; there's still an #else case with PR_CreateProcess but I don't think any current platform is using it. Given that the problem here is specific to Unix, I think this bug can be closed.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.