[PATCH 11 of 11] merge: don't fiddle with name lookups or i18n in hot loops

[Isaac Jurado]

On Tue, Feb 12, 2013 at 12:15 PM, Idan Kamara <idankk86 at gmail.com> wrote:
> On Tue, Feb 12, 2013 at 1:01 PM, Isaac Jurado <diptongo at gmail.com> wrote:
>> As far as I know, the multiprocessing.Pool uses the same shared pipe
>> design with two locks (read and write) so there is only one process
>> operating on the pipe at a time.   On win32 there is no write lock,
>> though.
>
> I tried to check this earlier (by looking at /proc/<child>/fd) and it seemed
> like each process in the pool had its own pipe, but either way, it doesn't
> matter.

I didn't think about checking that (silly me), I just overviewed the code.

> Assuming multiprocessing.Pool "just works" with no drastic performance
> loss, it could be beneficial to go that route for obvious reasons (also,
> a simple test shows it can transparently raise exceptions that came
> from the pool in the master).

To be honest, the multiprocessing module does some pretty weird
things, like squences of peek + sleep or threading in the parent
process to combine data from different pipes into one queue.  I've
always had  the sensation of not really knowing what's going on behind
the scenes.  And for process management code, that really creeps me
out.  But it's just my humble opinion.

> It's not specific to the command server. Uncaught exceptions are
> handled in dispatch, the module that is used to invoke top level
> commands. Then, they're transformed to an exit code which is returned
> to the caller: 'hg' simply calls sys.exit with it while other callers use it
> differently (command server sends it to the client and goes back to
> listening).

Right, so the communication is not really dropped.  The command server
uses pipes, is that right?

-- 
Isaac Jurado

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