On Tue, Jan 20, 2015 at 2:51 PM, Dmitriy Matrosov <sgf.dma@gmail.com> wrote:
then there is no (Show a, Read a) constraint. It will come
up only, when i mention PersistentExtension in one of case
branches, but, on the other hand, may be i can avoid

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.
 
Well, i've just tried to restart xmobar properly, when i
reload xmonad. I've noticed, that xmobar restarts with
xmonad only, when it uses StdinReader (in template),
otherwise new (another) xmobar instance spawned.

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).

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.

(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!)

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net