check out vfork if you are using fork just to call exec afterwards.
I think there are also a few other ways to make fork->exec less wasteful. I know windows has a syscall that bundles them into one so it can presumably skip the fork

>>108220019
vfork is effectively useless on modern linux systems. it is technically better, but only barely

also bampu

>>108220019
>I know windows has a syscall that bundles them into one so it can presumably skip the fork
Windows doesn't use fork. It doesn't copy the address space at all. That's Unix brain damage that normal operating systems don't do.

>>108220577
did you post this during your forced factorio autosave break?

these arent SYSCALLs retard, its gnusoid LIBC's abstractions

>>108220651
execve is the syscall, the $PATH-searching env-excluding alphabet soup is userland mental illness

File: img-2026-02-23-19-55-13.jpg (90 KB, 1024x576)

90 KB JPG

>>108220631

>>108220577
Fork is really nice for running stuff like servers or ML training

>parse arguments
>load bloated config file
>load all the data you need
then
>fork into a bunch of processes to run faster but without having to bloat up with multiple copies of your config/data
>fork for each chunk of work so that errors don't bring down the whole run
>fork for each connection for isolation

it's good. I guess it can work on the reverse side too, like in factorio where you share the main process and fork the saving.

>>108220778
they arent syscalls but LIBC abstractions, youve been brainwashed to that word, look in those MANs, there is said its LIBC.

>>108220019
>check out vfork if you are using fork just to call exec afterwards.
really doesn't matt on modern systems, fork is always copy-on-write.
>>108220577
how is address space copying brain damage? because of muh overhead(irrelevant with cow)? for many purposes threads are superior, sure, but having a wealth of well-delineated options is always a good thing.
>>108221943
>they arent syscalls but LIBC abstractions
barely so. execve's wrapper is auto-generated because all it does is move arguments into appropriate registers and sets rax and errno, so about as basic as a syscall in a high level language like C could be.

>>108221943
It says (2) so it's real

>>108222322
>because of muh overhead(irrelevant with cow)?
https://lwn.net/Articles/908268/
>But that is just a baseline for a process without much memory. If the parent allocates 1GB, the cost goes up a little bit to 56.4µs. But it turns out that Linux has some "clever optimizations" to handle the common case where processes allocate a lot more memory than they actually use. If the parent process touches all of the 1GB that it allocated, things get much worse, though: over 7500µs (or 7.5ms)
>7.5ms to spawn a process
>irrelevant
>>108220064
posix_spawn uses it and is faster than fork/exec because of it, so it's definitely not irrelevant.
>>108219864
One of the best syscalls, unlike fork.

>>108222322
>how is address space copying brain damage? because of muh overhead(irrelevant with cow)? for many purposes threads are superior, sure, but having a wealth of well-delineated options is always a good thing.
Try changing a feature from being implemented in the kernel to being implemented in a DLL or a separate process. Without fork, programs would work the same way and you won't have to know. Fork breaks everything.

>>108219864
a nice explanation of the syscall would help, especially us tardnormies that actually want to learn.

i like your posts, top 5 best threads on /g/, keep it up.

>>108224444
i can probably try to do that. in theory, that's what including the manpage is supposed to accomplish, but i guess it's reasonable to request a tl;dr on top of that. the only issue is that i tend to be a bit busy/rushed in the mornings. but i can certainly give it a try

>>108219864
execve() is based because it takes a list of arguments
on windows you pass them as a string and pray that the program parses it the way you assumed it would

also bampu

>>108224023
lwn isn't loading, I'll have another try later.
are those numbers with portions of the process space being written to? or is that the initial copy?
>>108224310
wdym? obviously process creation could never be implemented in user space, always requiring kernel support. are you referring to user level threads?
what's "a feature"

>>108226318
>obviously process creation could never be implemented in user space
not with that attitude

last bampu (for now)

File: 6g5kv8l08ieg1.jpg (67 KB, 640x640)

67 KB JPG

>>108228152
2 days of quite successful threads, huh. Was very nice to see
(this post is sage'd)