fest(std/node): implement os.getPriority() and os.setPriority()

[ecyrbe]

this PR implement node os priority feature. see #3802 and #3403 .

It looks like it adds errno dependency, but is was already used by our current dependencies and listed in cargo.lock.

it uses our current dependencies to implement these functionalities :

• unsafe libc for unix
• unsafe winapi for windows

a new internal crate (file priority.rs) was created to hide implementation the details from ops part.

[cknight]

Looks like the test for API not yet implemented still contains calls to os.getPriority() and os.setPriority(). Hopefully those tests now fail! See lines 212 and 226 in std/node/os_test.ts.

[ecyrbe]

Looks like the test for API not yet implemented still contains calls to os.getPriority() and os.setPriority(). Hopefully those tests now fail! See lines 212 and 226 in std/node/os_test.ts.

Thanks for the catch. the test for the api was implemented, but these one where not removed.

[ecyrbe]

@cknight @ry this is ready for review if you want

[cknight]

Thanks @ecyrbe, I've added a few suggestions, but will leave the rust review to @ry.

One further suggestion, what about making the different priority levels exposed as an enum, similiar to https://nodejs.org/api/os.html#os_priority_constants? This would make it more user friendly.

Then the API could be something like:

setPriority(priority: number | OsPriority, pid?:number)

[ecyrbe]

Thanks @ecyrbe, I've added a few suggestions, but will leave the rust review to @ry.

One further suggestion, what about making the different priority levels exposed as an enum, similiar to https://nodejs.org/api/os.html#os_priority_constants? This would make it more user friendly.

Then the API could be something like:

setPriority(priority: number | OsPriority, pid?:number)

i'll definitly add this to Deno api layer to ease deno developpement.

[cknight]

Thanks, LGTM once the CI passes. Rust code still needs reviewed by someone with Rust experience.

[ry]

Looks good! Just a few minor comments...

[ry]

I'm not sure what permissions this needs, but surely both set and getPriority should not be allowed in the default mode.

[ecyrbe]

Should i set Env permissions ?

[ecyrbe]

@ry Or should we create a new permission level? like :

• allow_api
• api_whitelist

[ecyrbe]

@ry just a reminder, could you give me a hint at what route i should take for permissions ? see above comment.

[ry]

We've discussed this. For now we'd like to require --allow-all in order to issue these calls. This is niche functionality and it certainly requires permissions, we're not keen on adding a new class of permissions just for this at this time. In the future, if people want it, we can introduce some more precision here - but --allow-all is a safe way to move forward.

[ecyrbe]

thanks. i agree, i'll add it then.

[ry]

@ecyrbe I'm sorry we couldn't get this in. I'm going to close this because it's stale. In the future when we try to implement this again we will refer back to this patch. But at the moment the permissions situation is unresolved and the patch is now quite out of date. I'm going to close this because it's stale. I appreciate the work - it sucks when we don't land nice patches like this.