[PATCH 11 of 11] merge: don't fiddle with name lookups or i18n in hot loops
idankk86 at gmail.com
Tue Feb 12 09:48:30 CST 2013
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...
More information about the Mercurial-devel