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

Isaac Jurado diptongo at gmail.com
Tue Feb 12 05:01:11 CST 2013


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've never used the command server, so I need to ask: what does it do
when it raises an exception?

-- 
Isaac Jurado

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


More information about the Mercurial-devel mailing list