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

[Idan Kamara]

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:
> > On Tue, Feb 12, 2013 at 3:02 AM, Bryan O'Sullivan <bos at serpentine.com>
> > wrote:
> >>
> >> On Sun, Feb 10, 2013 at 3:25 AM, Idan Kamara <idankk86 at gmail.com>
> >> wrote:
> >>>
> >>> No, he didn't. And had he given me the chance to reply to his last
> >>> response, I would have shown it:
> >>
> >>
> >> Yep, that's a bug. But it's just a bug - I fixed another one in the new
> >> parallel code just a little while ago.
> >
> > So we should exit on all exceptions, but we can't print a traceback
> > since that's not desirable when not running from the command line
> > (and it wasn't readable anyway since they got interleaved in one
> > another).
> >
> > 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130212/bb5ce59d/attachment.html>