[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