Opened 2 years ago

Closed 20 months ago

Last modified 9 months ago

#13446 closed enhancement (fixed)

POSIX: add posix_spawnp(), posix_spawn()

Reported by: korli Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: System/POSIX Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: yes Platform: All

Attachments (1)

0001-libroot-add-posix_spawn.patch (16.0 KB) - added by korli 20 months ago.
Library implementation of posix_spawn

Download all attachments as: .zip

Change History (9)

comment:1 Changed 20 months ago by korli

Has a Patch: set

Changed 20 months ago by korli

Library implementation of posix_spawn

comment:2 Changed 20 months ago by korli

I added an implementation of posix_spawn and its utility functions. It uses vfork/fork with execve/execvpe. The child status is eventually returned over a pipe to the parent. The test usecase only covers the use of posix_spawn without file actions or spawnattr.

Please review.

comment:3 Changed 20 months ago by axeld

Looks good to me.

comment:4 Changed 20 months ago by korli

Resolution: fixed
Status: newclosed

Thanks! BTW do you know whether a real vfork() would make sense for us?

Applied in hrev51418.

comment:5 Changed 20 months ago by pulkomandy

vfork is removed from issue 7 of POSIX, because when you have posix_spawn and a fork that does copy-on-write, there is really no need for it. So, it seems safe to forget about it and focus on making our fork implementation efficient (if it isn't already).

comment:6 Changed 20 months ago by korli

posix_spawn() could use a kern_vfork() (nothing POSIX) instead of fork(), because it's not really needed to copy the process memory when exec() is used just after. Out of memory on fork() seem very common.

IMO fork() isn't efficient to be used for posix_spawn(), an alternative would be nice.

comment:7 Changed 20 months ago by pulkomandy

The idea in Linux is to implement fork with copy-on-write, so no need to actually copy any of the data when forking (just the memory mapping needs to be copied and made read-only). However this would conflict with our "don't overcommit memory" management.

So, a vfork-style syscall to be used inside posix_spawn may be useful. But it seems one can get in a lot of trouble when multiple threads are involved, for example (in principle, vfork should block all of them in the parent until the child is done with its exec or exit). This is why making fork() as quick as possible may actually be a better idea.

comment:8 Changed 9 months ago by waddlesplash

However this would conflict with our "don't overcommit memory" management.

+1 to our "don't overcommit memory" system. Linux's model makes sense for servers where "usually" overcommitted memory is not a problem, but fork failures due to OOM would be; whereas non-overcommission makes more sense for GUI OSes where users expect applications to not be killed for no apparent reason under high-memory-usage scenarios.

But it seems one can get in a lot of trouble when multiple threads are involved, for example (in principle, vfork should block all of them in the parent until the child is done with its exec or exit).

How so? Since page tables and alternative threads are not copied, can't we just copy everything but the virtual address space (well, including the stack of course)? It doesn't sound too difficult to implement vfork(), actually.

Note: See TracTickets for help on using tickets.