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

[Idan Kamara]

On Tue, Feb 12, 2013 at 5:03 PM, Isaac Jurado <diptongo at gmail.com> wrote:
>
> 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.

My experience with it is fairly superficial so you could be right. But
it was just a suggestion that going with something that (should be)
fairly well tested and cross-platform could help us in the long run.

Perhaps someone who used it more extensively can weigh in.

>
> > 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?

Yes, although there's at least one implementation out there (that I
know of) that uses sockets.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130212/64112a29/attachment.html>