Minitest Process.fork regression

ruby-talk
1

Hi,

I would greatly appreciate if some other developers could chime in on this
issue https://github.com/seattlerb/minitest/pull/429

Because minitest is now used as the default testing tool in Ruby, I think
it is important to resolve this issue correctly.

Thanks
Samuel

2

Sorry it's not convenient for me to login to GH (and I may not have Internet
access again until next week). Feel free to forward my comments there (but I
know minitest devs also watch this list).

Anyways, I have a workaround in yahns where I install my own at_exit
handler and only run MT if TSTART_PID == $$:

  git clone git://yhbt.net/yahns.git
  cat yahns/test/helper.rb

In my case I testing process management + signal handlers in multiple threads
and also want a clean namespace for loading outside code. yahns may also
load/run outside code which depends on at_exit, so using exit! in yahns is not
an option.

yahns only runs on platforms which allow access to _oneshot_ kqueue/epoll
notifications, so portability to fork-less platforms is the least of my
concerns.

···

Samuel Williams <space.ship.traveller@gmail.com> wrote:

I would greatly appreciate if some other developers could chime in on this
issue https://github.com/seattlerb/minitest/pull/429

3

Thanks, that is a great example of why this is a big issue.

···

On 15 May 2014 14:57, Eric Wong <normalperson@yhbt.net> wrote:

Samuel Williams <space.ship.traveller@gmail.com> wrote:
> I would greatly appreciate if some other developers could chime in on
this
> issue https://github.com/seattlerb/minitest/pull/429

Sorry it's not convenient for me to login to GH (and I may not have
Internet
access again until next week). Feel free to forward my comments there
(but I
know minitest devs also watch this list).

Anyways, I have a workaround in yahns where I install my own at_exit
handler and only run MT if TSTART_PID == $$:

        git clone git://yhbt.net/yahns.git
        cat yahns/test/helper.rb

In my case I testing process management + signal handlers in multiple
threads
and also want a clean namespace for loading outside code. yahns may also
load/run outside code which depends on at_exit, so using exit! in yahns is
not
an option.

yahns only runs on platforms which allow access to _oneshot_ kqueue/epoll
notifications, so portability to fork-less platforms is the least of my
concerns.

4

Sorry to double reply, but at your earliest convenience feel free to drop
into the discussion to add your feedback :smiley:

···

On 15 May 2014 15:22, Samuel Williams <space.ship.traveller@gmail.com>wrote:

Thanks, that is a great example of why this is a big issue.

On 15 May 2014 14:57, Eric Wong <normalperson@yhbt.net> wrote:

Samuel Williams <space.ship.traveller@gmail.com> wrote:
> I would greatly appreciate if some other developers could chime in on
this
> issue https://github.com/seattlerb/minitest/pull/429

Sorry it's not convenient for me to login to GH (and I may not have
Internet
access again until next week). Feel free to forward my comments there
(but I
know minitest devs also watch this list).

Anyways, I have a workaround in yahns where I install my own at_exit
handler and only run MT if TSTART_PID == $$:

        git clone git://yhbt.net/yahns.git
        cat yahns/test/helper.rb

In my case I testing process management + signal handlers in multiple
threads
and also want a clean namespace for loading outside code. yahns may also
load/run outside code which depends on at_exit, so using exit! in yahns
is not
an option.

yahns only runs on platforms which allow access to _oneshot_ kqueue/epoll
notifications, so portability to fork-less platforms is the least of my
concerns.

5

> Thanks, that is a great example of why this is a big issue.

I do not consider this a big issue (which is why I did not bring it up
earlier). Keep in mind yahns is a fringe project with no relevant users.

Sorry to double reply, but at your earliest convenience feel free to drop
into the discussion to add your feedback :smiley:

Addendum: the yahns workaround (which is also like the pull #429
proposed) is not resilient to PID recycling in case the original PID
goes away. However, there may not be any test suites which trigger PID
recycling on the original PID (yahns certainly does not).

Anyways I tried replying via email by setting the In-Reply-To: header to
<seattlerb/minitest/pull/429@github.com> and
<seattlerb/minitest/issues/429@github.com> and failed both times. I
guess the reply+XXXXXXX part is relevant to their issue tracker; but I
couldn't be bothered to figure the hash/IDs out.

The mental anguish from a website login (especially for a proprietary
site) is too much for a minor issue. You may quote or link to my
mailing list posts if you think it's important.

···

Samuel Williams <space.ship.traveller@gmail.com> wrote:

On 15 May 2014 15:22, Samuel Williams <space.ship.traveller@gmail.com>wrote: