Make workers by default not call parent's at_exit handlers at exit

[dpsi]

Cucumber unfortunately utilizes the at_exit method as hook. The Parallel gem by default uses the Kernel#fork method which means that when the forked process exits, it will call the parent's at_exit handler. I am not sure if this is intended behaviour for the Parallel gem, but it does cause some unexpected bugs to occur in cucumber, or any other program that uses at_exit in a similiar way. Capybara, minitest, are some others I think use at_exit like this.

Here is the issue I opened with cucumber: cucumber/cucumber-ruby#1327

I was wondering if there was any interest in making Thread the default, or perhaps changing how the #fork workers exit. I think calling exit! will make it not call the parents at_exit handlers, but calling that from inside the Parallel block (in user code) ended up with Deadworker exception which makes sense after perusing the code.

PS: I love how this gem is essentially 1 file, very nice concise code

[grosser]

I'm scared of making it use at_exit since that's a callback users expect. simple_cov and others have workarounds for that, so maybe find inspiration from them otherwise having an optional `hard_exist: true` flag would be a nice workaround that does not break other peoples workflows/expectations

…

On Wed, Nov 14, 2018 at 2:39 PM Darien ***@***.***> wrote: Cucumber unfortunately utilizes the at_exit method as hook. The Parallel gem by default uses the Kernel#fork method which means that when the forked process exits, it will call the parent's at_exit handler. I am not sure if this is intended behaviour for the Parallel gem, but it does cause some unexpected bugs to occur in cucumber, or any other program that uses at_exit in a similiar way. Capybara, minitest, are some others I think use at_exit like this. Here is the issue I opened with cucumber: cucumber/cucumber-ruby#1327 <cucumber/cucumber-ruby#1327> I was wondering if there was any interest in making Thread the default, or perhaps changing how the #fork workers exit. I think calling exit! will make it not call the parents at_exit handlers, but calling that from inside the Parallel block (in user code) ended up with Deadworker exception which makes sense after perusing the code. PS: I love how this gem is essentially 1 file, very nice concise code — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#230>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAsZ4woDDHjQmZEaPt487CO9hBuvEfHks5uvJuQgaJpZM4YeuJe> .

[dpsi]

I don't suppose there is a way to globally configure Parallel to default to threads instead of Kernel#fork? Reason being is that I don't have control over how others use Parallel so while my own code would be cucumber-safe, others would not.

[grosser]

Parallel default method is fork since that's what helps the most and is the hard problem parallel is supposed to fix. (parallel threading is simple and does not really need a gem)

…

On Wed, Nov 14, 2018 at 3:31 PM Darien ***@***.***> wrote: I don't suppose there is a way to globally configure Parallel to default to threads instead of Kernel#fork? Reason being is that I don't have control over how others use Parallel so while my own code would be cucumber-safe, others would not. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#230 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAsZ3CuERsMqo2k3fOSpOro-xOC3DQWks5uvKfGgaJpZM4YeuJe> .

[dpsi]

After some more reading I see why fork is the default, which also led me to conclude that using Thread for my usecase also defeats the purpose of splitting up the work load. (Thanks GIL!)

Anyways, in a future version, having that option not to call the parent at_exit handlers would be nice to have.

[grosser]

Want to make a PR for that ? :)

…

On Wed, Nov 14, 2018 at 4:08 PM Darien ***@***.***> wrote: After some more reading I see why fork is the default, which also led me to conclude that using Thread for my usecase also defeats the purpose of splitting up the work load. (Thanks GIL!) Anyways, in a future version, having that option not to call the parent at_exit handlers would be nice to have. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#230 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAsZzjCoVxh2JE_vFDyzvf7edg2MDSyks5uvLBhgaJpZM4YeuJe> .