Creating a process in a keybinding fails

[noughtmare]

Problem Description

Creating a process in a keybinding fails. I know this can be fixed by using
xfork, but I would like to know why it does not work like this.

See this reddit thread.

Configuration File

{-# LANGUAGE TypeApplications #-}
module Main (main) where

import XMonad
import System.Process (readProcess)
import Control.Monad (void)
import Data.Map (singleton)
import Control.Exception (try, SomeException)

main :: IO ()
main = xmonad def
  { keys = \cfg ->
      singleton
        (modMask cfg, xK_a)
        (io $ do
          x <- try @SomeException (readProcess "dmenu" [] "")
          case x of
            Left e -> spawn ("xmessage \"Error: " ++ show e ++ "\"")
            Right _ -> spawn "xmessage Good!")
      <> keys def cfg
  }

This first starts dmenu normally then after you press enter (or escape) it opens an xmessage window with the text:

Error: waitForProcess: does not exist (No child processes)

Checklist

• I've read CONTRIBUTING.md

• I tested my configuration with xmonad-testing

xmonad-testing does not seem to be up-to-date anymore? I've tested this with xmonad 0.15 from Hackage.

[geekosaur]

There's a module that gives you a function that will work (Xmonad.Util.Run.readProcessWithTimeout and similar). Xmonad, like most window managers, does not use POSiX process control but arranges for child processes to be automatically reaped (see SIG_IGN on SIGCHLD). This means operations expecting standard process control will get back -1 from waitpid() which leads to an exception in Haskell. There's an additional reason for this and in particular the timeout: time spent waiting on a process including for output from it is time spent not managing windows. In particular this means whatever process you want to spawn shouldn't open a window unless it sets override_redirect on it, or the window won't be displayed.

…

On Sat, Jul 18, 2020, 09:48 Jaro Reinders ***@***.***> wrote: Problem Description Creating a process in a keybinding fails. I know this can be fixed by using xfork, but I would like to know why it does not work like this. See this reddit thread <https://old.reddit.com/r/xmonad/comments/hsir6n/why_does_my_function_to_get_values_from_file/> . Configuration File {-# LANGUAGE TypeApplications #-}module Main (main) where import XMonadimport System.Process (readProcess)import Control.Monad (void)import Data.Map (singleton)import Control.Exception (try, SomeException) main :: IO () main = xmonad def { keys = \cfg -> singleton (modMask cfg, xK_a) (io $ do x <- try @SomeException (readProcess "dmenu" [] "") case x of Left e -> spawn ("xmessage \"Error: " ++ show e ++ "\"") Right _ -> spawn "xmessage Good!") <> keys def cfg } This first starts dmenu normally then after you press enter (or escape) it opens an xmessage window with the text: Error: waitForProcess: does not exist (No child processes) Checklist - I've read CONTRIBUTING.md <https://github.com/xmonad/xmonad/blob/master/CONTRIBUTING.md> - I tested my configuration with xmonad-testing <https://github.com/xmonad/xmonad-testing> x — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#229>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPRFIGNH6AXPOOGXIPJNNDR4GR4LANCNFSM4O752H4A> .

[noughtmare]

Thanks for the quick reply.

Am I right when I conclude from your response that avoiding freezing the window manager is the main reason for disabling child processes? In that case wouldn't you want to restrict the X monad even more, so that you can only do non-blocking IO? Keybindings could be changed to the type IO (X ()) such that they are always xforked and the resulting X action is only executed when the IO action finishes. I think that would be even safer. But maybe this is too complicated.

It is also not very good at 'reaping' child processes, because you can still start dmenu without problems, it only returns an error code when the process finishes. That still means that Xmonad is frozen for an indefinite amount of time.

[geekosaur]

Xmonad also isn't threaded, because X11 isn't really multithread capable: each request must lock the server connection and block until the reply comes in. Each thread would have to have its own server connection and thereby X monad. Having a finalized action could be done but is just chaining actions with `>>`. Having the key action always fork would prevent things like submaps or Xmonad.Prompt from working, not to mention blocking the action from making any changes to Xmonad's state.

…

On Mon, Jul 20, 2020, 09:27 Jaro Reinders ***@***.***> wrote: Thanks for the quick reply. Am I right when I conclude from your response that avoiding freezing the window manager is the main reason for disabling child processes? In that case wouldn't you want to restrict the X monad even more, so that you can only do non-blocking IO? Keybindings could be changed to the type IO (X ()) such that they are always xforked and the resulting X action is only executed when the IO action finishes. I think that would be even safer. But maybe this is too complicated. It is also not very good at 'reaping' child processes, because you can still start dmenu without problems, it only returns an error code when the process finishes. That still means that Xmonad is frozen for an indefinite amount of time. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#229 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPRFIHVMWFNY5VLTKYVXJTR4RA4BANCNFSM4O752H4A> .

[noughtmare]

I meant more like having the IO action executed in a background thread that returns an X action that can be put on some kind of queue to be executed in the main Xmonad thread. But, I see that there are still many other problems with such an approach.