It's a very comfy syscall indeed.
Now quiz time: what happens when a child process finishes executive but the result is not requested from the parent process?

File: 1765132318589720.jpg (49 KB, 550x535)

49 KB JPG

>>108100361
What's the difference between a fork() and a thread?

>>108100361
stop making these shit threads hon

File: 1767523661340138.jpg (29 KB, 300x391)

29 KB JPG

>>108100601
fork creates a new process.
On linux, it's very fast because of low overhead.
On windows, however, it invokes a gazillion of events, that's why you shouldn't run postgres on windows.

>>108100361
syscalls are based but you're an ultrafaggot and you should 41% yourself

File: 1754508482620066.jpg (25 KB, 640x354)

25 KB JPG

>>108100361
god i wish i could get ttied

File: 1749674329292118.jpg (37 KB, 720x680)

37 KB JPG

>>108100886
We've reached 50

>>108100361
How do you guarantee that a function will always be successful?

>>108100979
good

>>108100601
You can't post new forks on /g/.

>>108101019
If you're running, you have a process and a thread, which can be read out and returned.
If you aren't running, you therefore don't need anything to be read out and returned.

>>108100601
Linux has no threads.

>>108101213
Kek

>>108100361
>twitter screencap thread
I no longer like you

>>108100361
>tiny waists
>laced in corsets
born in the wrong time, lads. Never felt it stronger than today

>>108100524
>what happens when a child process finishes executive but the result is not requested from the parent process?
a zombie process is created, and it only dies when either:
a. parent eventually waits on child process.
b. parent process dies and zombie gets waited on by pid 1.

>>108101596
it does. both processes and threads are scheduled as tasks in the kernel, that's true, but the degree of shared memory segments differentiate the two.

>>108100524
you're a little unclear, but are you referring to zombie processes, or what?

>>108100361
>>These functions are always successful.
>is pretty cool lol.
yea, for some reason I really like that as well. Dunno what it is.
>some of my all-time most used syscalls
I don't use these that much actually. my most used by far are the classic open/close/read/write/mmap quinfecta.

>>108100361
I love writing

// SAFETY: this call is always safe
let pid = unsafe { libc::getpid() };

>From glibc 2.3.4 up to and including glibc 2.24, the glibc wrapper function for getpid() cached PIDs, with the goal of avoiding additional system calls when a process calls getpid() repeatedly. Normally this caching was invisible, but its correct operation relied on support in the wrapper functions for fork(2), vfork(2), and clone(2): if an application bypassed the glibc wrappers for these system calls by using syscall(2), then a call to getpid() in the child would return the wrong value (to be precise: it would return the PID of the parent process). In addition, there were cases where getpid() could return the wrong value even when invoking clone(2) via the glibc wrapper function. (For a discussion of one such case, see BUGS in clone(2).) Furthermore, the complexity of the caching code had been the source of a few bugs within glibc over the years.
>Because of the aforementioned problems, since glibc 2.25, the PID cache is removed: calls to getpid() always invoke the actual system call, rather than returning a cached value.
Huh
I thought they had vDSO for things like that but I guess the PID is both easy to cache in user code and hard to efficiently provide to multiple processes