<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 20, 2015 at 2:51 PM, Dmitriy Matrosov <span dir="ltr"><<a href="mailto:sgf.dma@gmail.com" target="_blank">sgf.dma@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">then there is no (Show a, Read a) constraint. It will come<br>
up only, when i mention PersistentExtension in one of case<br>
branches, but, on the other hand, may be i can avoid<br>
</blockquote><div><br></div><div>That would be expected, I believe; if you mentioned it, it must apply to the whole instance, not just one case branch. But I'm not quite clear on what you are saying here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, i've just tried to restart xmobar properly, when i<br>
reload xmonad. I've noticed, that xmobar restarts with<br>
xmonad only, when it uses StdinReader (in template),<br>
otherwise new (another) xmobar instance spawned.<br></blockquote><div><br></div><div>That is expected. You are expecting some kind of magic happening where we track every pipe and forcibly terminate all of them, when all we are doing is using normal POSIX semantics where pipes get closed automatically but the process on the other side will only find out if it is reading from the pipe (i.e. xmobar's StdinReader).</div><div><br></div><div>Doing the magic that you and others seem to expect would be in one way or another very expensive --- either we make xmonad only work on one particular OS family, or we accept that we can only spawn so many pipes because of child process limits, or we have to make spawnPipe spawn a backchannel to report the ultimate child *and* we must restrict what kinds of things you can run on the other end so we can keep track and kill it.</div><div><br></div><div>(You probably want to consider the above with respect to your proposed extension; the POSIX subprocess model has many dark corners. In particular, remember that the child process "closest" to xmonad in a spawnPipe is a shell, *not* the program you ran. And that shell has the same problem, so killing it will not kill the xmobar it starts!)</div><div><br></div></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh                               sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>                                  <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad        <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</div></div>