Thread #108565168
File: 1732492935660840.png (16.7 KB)
16.7 KB PNG
previous: >>108557703#define __NR_getpriority 140
#define __NR_setpriority 141
https://man7.org/linux/man-pages/man2/setpriority.2.html
tl;dr:
manage your process's scheduling priority
was conflicted about if i should merge tomorrow's syscalls into this one, but i figured i would keep these separate and do all of the sched_* ones at once
you'll probably want to see also https://man7.org/linux/man-pages/man2/nice.2.html and https://man7.org/linux/man-pages/ma n7/sched.7.html
nice values are just... bizarreThe range of the nice value varies across UNIX systems. On modern
Linux, the range is -20 (high priority) to +19 (low priority). On
some other systems, the range is -20..20. Very early Linux
kernels (before Linux 2.0) had the range -infinity..15.
i'm sure there's some sort of logic to it, and i could certainly look it up, but maybe someone else already knows and would like to share? let's get some audience participation going!
of interest (to me, at least) is:C library/kernel differences
The getpriority system call returns nice values translated to the
range 40..1, since a negative return value would be interpreted as
an error. The glibc wrapper function for getpriority() translates
the value back according to the formula unice = 20 - knice (thus,
the 40..1 range returned by the kernel corresponds to the range
-20..19 as seen by user space).
so why even have them be negative in the first place...? goodness!
tomorrow i will probably try to jump start some scheduling algorithm discussion in the thread, but feel free to share your thoughts now, if you have any
the only other thing that really stands out to me today is probably the bugs section:According to POSIX, the nice value is a per-process setting.
However, under the current Linux/NPTL implementation of POSIX
threads, the nice value is a per-thread attribute: different
threads in the same process can have different nice values.
Portable applications should avoid relying on the Linux behavior,
which may be made standards conformant in the future.
i do think a per-thread implementation is the sane choice, though
relevant resources:man manman syscalls
https://man7.org/linux/man-pages/
https://linux.die.net/man/
https://elixir.bootlin.com/linux/
https://elixir.bootlin.com/musl/
https://elixir.bootlin.com/glibc/
41 RepliesView Thread
Showing all 41 replies.>>
>>
>>108565194
i'm like halfway through and want to finish what i started! i probably won't end up doing something like this again in the future, though, because yes it's pretty clear that most people on /g/ aren't interested in this sort of thing. but it's been a nice source of consistency in my life so far this year
>>
>>
File: 1775699042922261.png (22.9 KB)
22.9 KB PNG
do syscalls for all operating systems after you finish linucks
>>
>>
>>
>>
>>
>>108565168
A "nice" value is literally supposed to denote the literal "niceness" of the selected entity. A high "nice" value means that it will let others run first (i.e. being extra nice), a low or negative value means that it will demand runtime before anyone else (i.e. being quite egotistical).
>autists trying to be funny again
>>
>>108566677
midway through my first job, when i got assigned to some tough tasks that no one else had the time to do. i had to buckle down and handle it. i actually did quite poorly in college. i'm much better in the corporate world, i guess
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>108567475
I don't really program in rust because it feels like a very "enterprise" language designed to be like nu cpp or java, worked on by horses of people that are unfamiliar with 90% of the codebase
however I would still read your threads and it might convince me to try harder at it
>>
>>108567492
>horses
hordes. I abhor enterprise codebases which is what I do at work, so I wouldn't want to engage in that in my free time.
I'm more interested in one-man or small team projects like zig because they end up being much more opinionated and sovl. Hell even Go feels more opinionated
>>
>>
>>
>>108567492
Rust solves issues only stage n programmers have: https://www.youtube.com/watch?v=xt1KNDmOYqA
>>
File: EbxzPMtU4AAar2i.jpg (591.5 KB)
591.5 KB JPG
>>108567475
>I'm planning on creating a thread series for the accepted Rust RFCs.
Sounds like blackmail!
Turning the syscalls into fine tuned hand optimized RISC-V assembly would be more interesting and also probably engage more regulars.
>>
>>
>>108568085
>You'll still require a mode switch
Not sure what you mean, but someone has started this:
https://www.phoronix.com/news/Linux-7.1-RISC-V-strnlen
>>
>>
>>108567897
>stage n programmer
tf does that mean
>>108567528
well yes edgy stuff is what shapes fields, safe things are boring and only pad until the next big thing
>>
>>108568212
>strnlen
That's not a mode switch. Fuck, I can implement that one in the finest SIMD without a single mode switch: https://lock.cmpxchg8b.com/zenbleed.html
>>
File: vitality_ups.png (2.9 MB)
2.9 MB PNG
>>108568265
Fuck, meant to reply to >>108568248.
I blame the gin.
Anyway, go watch the video, I'm busy farming sources.
>>
>>
File: Chlorine-trifluoride-3D-vdW.png (201.5 KB)
201.5 KB PNG
>>108568085 >>108568265
The mode switch has a cost but that doesn't stop anyone from optimizing the rest.
Many syscalls are handled by the C libraries, do all of those also require a mode switch?
>>
File: syscall_ntdll.png (14.5 KB)
14.5 KB PNG
>>108568926
>Many syscalls are handled by the C libraries,
That's ... literally not how this shit works
>>
>>
File: file.png (43.7 KB)
43.7 KB PNG
>>108568068
RISC-meme is for sissies
>>108565168
The return value of 40 confused me for a bit.
>so why even have them be negative in the first place...? goodness!
This is what happens when you shoehorn a POSIX standard onto a different interface
>>
>>