I cannot lie, fork() is one of my favorite syscalls.
-
-
Replying to @halvarflake
fork() is just a special case of clone(), clone() is way cooler. also, for some usecases, fork() isn't really the right primitive
1 reply 0 retweets 13 likes -
Replying to @tehjh @halvarflake
Isn't that just the Linux way of thinking? - Also when would you use clone() directly, I would always use either pthread_* calls or fork(), but never felt the urge to use clone() directly.
1 reply 0 retweets 0 likes -
Replying to @sigttou @halvarflake
threads that don't share the fd table, so that fdget() and fdput() are faster. child processes that do share the fd table. threads that can set their own umask and cwd instead of sharing them with all their sibling threads (secure bind() on unix domain sockets requires umask).
1 reply 0 retweets 0 likes -
fun fact: most syscalls that operate on existing file descriptors (read(), write(), ...) become slower if the file descriptor table is shared with another task (more precisely, if its refcount is >1), which is the case if you're using normal threads
1 reply 0 retweets 5 likes -
-
-
Replying to @sigttou @halvarflake
it comes from this microoptimization in __fget_light(), saving two atomic operations on the struct file (with the associated cacheline bouncing) per syscall: https://elixir.bootlin.com/linux/v4.20.12/source/fs/file.c#L743 …
1 reply 0 retweets 2 likes
(or at least that's where it AFAIK should come from)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.