Re: [hackers] Re: [PATCH] dd: Use sigaction(2) to obviate select(2)

[Eric Pruitt]

On Sun, Oct 08, 2017 at 01:01:55PM -0700, Michael Forney wrote:
> I am curious why ubase dd is using splice instead of just read/write
> (as you noted most other implementations do). Unless there is a big
> performance win, I would think that simplicity and portability would
> be preferable.

I did some digging through the commit history when I created this patch
to find out why: the ubase dd(1) implementation is based on
https://github.com/stealth/odd.git which implements the techniques
described in http://stealth.openwall.net/papers/odd.pdf to improve the
performance of dd(1). That is not to say I agree the added complexity is
worth the performance improvement, but I at least understand the
motivation and think it's a reasonable goal.

Eric

Re: [hackers] Re: [PATCH] dd: Use sigaction(2) to obviate select(2)

[Michael Forney]

On 2017-09-17, Eric Pruitt  wrote:
> On Sun, Sep 10, 2017 at 04:31:24AM -0700, Eric Pruitt wrote:
>> By setting the SIGINT handler with sigaction(2), automatic retries of
>> the splice(2) syscall can be disabled by not setting SA_RESTART. This
>> makes it possible to use Ctrl+C even if the "if" operand refers to the
>> controlling terminal. The SIGINT message has also been moved outside the
>> signal handler since fprintf(3) is not an async-signal-safe function.
>
> I'm wondering if the ubase maintainer(s) have looked at this patch and
> whether or not they think there are some problems with it.

I can reproduce the issue (select spinning) and I verified that the
patch does indeed fix the issue, so I think it should be applied.

I am curious why ubase dd is using splice instead of just read/write
(as you noted most other implementations do). Unless there is a big
performance win, I would think that simplicity and portability would
be preferable.