standalone-enc: use processes instead of threads for socketpair_one

[gperciva]

No description provided.

[gperciva]

On bare-metal freebsd 14.0, there's a very slight increase in time by switching from threads to processes. I don't think it's relevant, but I figured I should mention it.

N=11 boxplot

overall

close-up of socketpair_one test

[cperciva]

I don't see any explanation of why you want this change?

[gperciva]

Two reasons:

1. this is closer to the way we'd normally use spiped (i.e. one process from spiped, and at least one other process piping data to it).

2. this will allow us to add a socketpair_two test (which has separate processes for encryption, decryption, input, and output), with less new code.

   We can't have encryption and decryption in the same process, because they rely on events_spin(), which isn't multi-thread-safe.

I can add this to the commit message for 7ab5011.

[cperciva]

Makes sense. Yes, please add some text to the relevant commit message.

[gperciva]

Updated.

FWIW, this PR changes from pthread_create_blocking_np to fork_func without any "blocking" functionality.

If I add that in -- making sure that the forked functions have started, before leaving pipe_init() -- then the forked version is slightly faster than both previous versions:

[gperciva]

Actually, wait, I want to revisit the number of open file descriptors in the forked processes. I'm not convinced it's wrong, but I'm also not convinced it's right.

[gperciva]

Actually, wait, I want to revisit the number of open file descriptors in the forked processes.

Never mind, this is the normal behaviour of fork.