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

[Idan Kamara]

On Tue, Feb 12, 2013 at 1:01 PM, Isaac Jurado <diptongo at gmail.com> wrote:
>
> On Tue, Feb 12, 2013 at 11:35 AM, Idan Kamara <idankk86 at gmail.com> wrote:
> > On Tue, Feb 12, 2013 at 12:12 PM, Isaac Jurado <diptongo at gmail.com>
> > wrote:
> >>
> >> On Tue, Feb 12, 2013 at 10:26 AM, Idan Kamara <idankk86 at gmail.com>
> >> wrote:
> >> >
> >> > Maybe we should serialize the exceptions to the master and have
> >> > him decide what to do (e.g. reraise)?
> >>
> >> That could be a problem if the serialized exception needs more than
> >> 512 bytes in size.  The elegance of Bryan's design relies on the fact
> >> that the operating system ensures atomicity for small writes to the
> >> shared pipe.
> >
> > Ok, and since we'd like to include the traceback, we'll most likely need
> > more than 512 bytes. So unless there's a trick to be made here, we'll
> > need a pipe for every worker.
> >
> > It might be worth looking at multiprocessing.Pool, which does all this
> > and has a chance of working sensibly on Windows too (there's a
> > backport of it to 2.4-5).
>
> 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.

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).

>
> I've never used the command server, so I need to ask: what does it do
> when it raises an exception?

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130212/f3e16c9d/attachment.html>