Parallel – A command-line CPU load balancer written in Rust • Hacker News Board

Re: Parallel – A command-line CPU load balancer written in Rust

#61

Post by [deleted] » Fri, Aug 26, 2016, 7:36 PM UTC

geofft wrote: post #59

the_mitsuhiko wrote: post #57

Earlier quoted context omitted.

Which proves my point. It's messy, inefficient and now you wrote code which is not composable as you have a global (and the only) signal handler.

I don't think it's less efficient than threads (but someone should test it!). It scales better. It's not composable, but it's not impossible to work around that if you can assume non-POSIX. Platforms with kqueue just get this right because kqueue can wait for processes. Linux will let you use a different signal to alert for process completion, so pick one of the realtime signals (which is its own game of global names…

[deleted]

Re: Parallel – A command-line CPU load balancer written in Rust

#62

Post by gpderetta » Fri, Aug 26, 2016, 9:52 PM UTC

the_mitsuhiko wrote: post #56

gpderetta wrote: post #32

Earlier quoted context omitted.

> The only thing you can do from a signal handler is flipping a static and only one signal handler can be set. This is false, you can call any async signal safe function. Incidentally write is one of them. Another trick is the close-on-exit pipe.

> This is false, you can call any async signal safe function. Incidentally write is one of them. Which malloc() is not. Anything that might internally allocate is out of the question. The list of functions that are safe to call in C alone is very limited and even then the question of errno arises.

why are you bringing up malloc?

Re: Parallel – A command-line CPU load balancer written in Rust

#63

Post by the_mitsuhiko » Fri, Aug 26, 2016, 10:56 PM UTC

gpderetta wrote: post #62

the_mitsuhiko wrote: post #56

Earlier quoted context omitted.

> This is false, you can call any async signal safe function. Incidentally write is one of them. Which malloc() is not. Anything that might internally allocate is out of the question. The list of functions that are safe to call in C alone is very limited and even then the question of errno arises.

why are you bringing up malloc?

Because you do not necessarily know which call will allocate memory in Rust and even in C it can be tricky. You literally can only go with the whitelisted functions.

Re: Parallel – A command-line CPU load balancer written in Rust

#64

Post by gpderetta » Sat, Aug 27, 2016, 3:14 PM UTC

the_mitsuhiko wrote: post #63

gpderetta wrote: post #62

Earlier quoted context omitted.

why are you bringing up malloc?

Because you do not necessarily know which call will allocate memory in Rust and even in C it can be tricky. You literally can only go with the whitelisted functions.

Yes, that's way you should, as I suggested, only call functions explicitly documented as asyc-signal-safe.

Re: Parallel – A command-line CPU load balancer written in Rust

#65

Post by Aissen » Mon, Aug 29, 2016, 8:05 AM UTC

ole_tange wrote: post #55

Aissen wrote: post #15

Not comparing it with the simpler, better moreutils parallel is really unfair.

I hope you wont take this the wrong way, but can you elaborate on why you feel Tollef's parallel (from moreutils) is better than GNU Parallel?

It was addressed elsewhere in the thread. My take is: 1/ it's written in C. 2/ it doesn't suffer from feature creep.

The code is 427 lines of C. GNU parallell is 10k+ lines of perl. Considering mmstick compares the loading times, it's easy to see where the difference comes from.