Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

A side-question is why this fails indefinitely instead of getting killed by a timeout.

the timeout is prob longer than the travis timeout

<@U054MQUPL>: Can you also "CI this" your fix branch?

I'd like to confirm this is working in Jenkins in well

Feel free to do it as many times as you feel necessary to be convinced it's fixed

And add some reasonable timeout to these configs

&gt; the timeout is prob longer than the travis timeout

i thought the pytest default timeout is 5m, travis is 10m

my guess is this is a hard hang w/ GIL, which prevents the pytest timeout thread/machinery from ever firing

not sure how the timeouts are implemented

ah via `threading.Timer`, so yeah - this can’t catch deadlock cases where the GIL is never released

What would be holding the GIL in this situation?

presumably whatever bad is happening in multiprocessing.pool when a child proc dies

<http://www.psf.upfronthosting.co.za/issue24927>

```When using Pool.apply, the task (function) is sent to the task queue, which is consumed by the worker. At this point the task is "in progress". However, the worker dies without being able to finish the task or in any other way tell the Pool that it can't finish the task. The actual process is then ended by the Pool but the task is still in limbo, so any attempt at getting a result will hang forever.```

Though I _still_ don't think it should be a GIL issue

But yeah, you'd think Python's story would be "yes we know we don't have real threading, but our processing primitives are great!"

it could be that the cleanup thread is firing, but just unable to do anything about the hang

No, the multiprocessing primitives are composed entirely of landmines