<div dir="ltr">On Tue, Feb 12, 2013 at 5:03 PM, Isaac Jurado <<a href="mailto:diptongo@gmail.com">diptongo@gmail.com</a>> wrote:<br>><br>> On Tue, Feb 12, 2013 at 12:15 PM, Idan Kamara <<a href="mailto:idankk86@gmail.com">idankk86@gmail.com</a>> wrote:<br>
> > On Tue, Feb 12, 2013 at 1:01 PM, Isaac Jurado <<a href="mailto:diptongo@gmail.com">diptongo@gmail.com</a>><br>> > wrote:<br>> >> As far as I know, the multiprocessing.Pool uses the same shared pipe<br>
> >> design with two locks (read and write) so there is only one process<br>> >> operating on the pipe at a time.   On win32 there is no write lock,<br>> >> though.<br>> ><br>> > I tried to check this earlier (by looking at /proc/<child>/fd) and it<br>
> > seemed<br>> > like each process in the pool had its own pipe, but either way, it<br>> > doesn't<br>> > matter.<br>><br>> I didn't think about checking that (silly me), I just overviewed the code.<br>
><br>> > Assuming multiprocessing.Pool "just works" with no drastic performance<br>> > loss, it could be beneficial to go that route for obvious reasons (also,<br>> > a simple test shows it can transparently raise exceptions that came<br>
> > from the pool in the master).<br>><br>> To be honest, the multiprocessing module does some pretty weird<br>> things, like squences of peek + sleep or threading in the parent<br>> process to combine data from different pipes into one queue.  I've<br>
> always had  the sensation of not really knowing what's going on behind<br>> the scenes.  And for process management code, that really creeps me<br>> out.  But it's just my humble opinion.<div><br></div>
<div><div>My experience with it is fairly superficial so you could be right. But</div><div>it was just a suggestion that going with something that (should be)</div><div>fairly well tested and cross-platform could help us in the long run.</div>
<div><br></div><div>Perhaps someone who used it more extensively can weigh in.</div></div><div><br>><br>> > It's not specific to the command server. Uncaught exceptions are<br>> > handled in dispatch, the module that is used to invoke top level<br>
> > commands. Then, they're transformed to an exit code which is returned<br>> > to the caller: 'hg' simply calls sys.exit with it while other callers<br>> > use it<br>> > differently (command server sends it to the client and goes back to<br>
> > listening).<br>><br>> Right, so the communication is not really dropped.  The command server<br>> uses pipes, is that right?<br></div><div><br></div><div>Yes, although there's at least one implementation out there (that I</div>
<div>know of) that uses sockets.</div></div>