On Tue, Jan 20, 2015 at 2:51 PM, Dmitriy Matrosov
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