[PATCH 3 of 3] worker: handle worker failures more aggressively

[Isaac Jurado]

On Wed, Feb 20, 2013 at 7:59 PM, Bryan O'Sullivan <bos at serpentine.com> wrote:
> On Wed, Feb 20, 2013 at 12:20 AM, Isaac Jurado <diptongo at gmail.com> wrote:
>>
>> What's the plan for Windows?  Threads or processes?
>
> Threads won't help, because update is partly CPU bound and threads
> will all serialize on the GIL.
>
> So if there's to be an answer for Windows, it has to be processes,
> presumably started via os.spawnv.
>
> I'm in no rush to implement a Windows solution. I don't expect an
> approach based on the multiprocessing module to be useful, because (a)
> people do all kinds of perverse packaging things on Windows that are
> unlikely to work with multiprocessing and (b) the multiprocessing
> module adds a ton of overhead, so you have to do a lot of work to
> overcome its communication costs.
>
> (We can't use any of the various "Windows has something sort of like
> fork(2)" approaches either, because they are all terribly broken.)

That's my point.  Working with processes on Windows is going to be
different enough from the other platforms, right?

And let me quote your earlier response:

> Process groups only exist on Unix. This code should (mostly?) work
> untouched on other platforms.

Don't you see a bit of contradiction here?  Please, don't get me wrong,
maybe I'm just failing to accept that my process group suggestion is not
as smart as I think it was.  But you have to understand that the given
reasoning about discarding Unix-only features is, at best, quite
confusing.  Specially when talking about the process model.

My apologies for being a bit of an ass, but I'm very interested in how
these patches evolve.

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci