spawn -package:abstract-par

Fork a new thread, create a new end point on that thread, and run the specified IO operation on that thread. Returns the address of the new end point.

Spawn a mailbox using the specified Buffer to store messages Using send on the Output

• fails and returns False if the mailbox is sealed, otherwise it:
• retries if the mailbox is full, or:
• adds a message to the mailbox and returns True.

Using recv on the Input:

• retrieves a message from the mailbox wrapped in Just if the mailbox is not empty, otherwise it:
• retries if the mailbox is not sealed, or:
• fails and returns Nothing.

If either the Input or Output is garbage collected the mailbox will become sealed.

spawn. Launch an external application. Specifically, it double-forks and runs the String you pass as a command to /bin/sh. Note this function assumes your locale uses utf8.

Create a concurrent computation for the provided action, and return a MVar which can be used to query the result.

create task threads faster, but with no thread control: spawn = freeThreads . waitEvents

Not on Stackage, so not searched. Tiny library for concurrent computations

Start up a concurrent process and get a reference to it

Creates a new process to run the specified shell command. It does not wait for the program to finish, but returns the ProcessHandle.

Creates a new process to run the specified raw command with the given arguments. It does not wait for the program to finish, but returns the ProcessHandle.

Lifted spawnCommand.

Lifted spawnProcess.

Executes a child program asynchronously. See spawnAsyncWithPipes for a full description; this function simply calls the spawnAsyncWithPipes without any pipes. You should call spawnClosePid on the returned child process reference when you don't need it any more. If you are writing a GTK application, and the program you are spawning is a graphical application too, then to ensure that the spawned program opens its windows on the right screen, you may want to use GdkAppLaunchContext, GAppLaunchContext, or set the DISPLAY environment variable. Note that the returned childPid on Windows is a handle to the child process and not its identifier. Process handles and process identifiers are different concepts on Windows.

Executes a child program asynchronously. Identical to spawnAsyncWithPipesAndFds but with n_fds set to zero, so no FD assignments are used. Since: 2.58

Identical to spawnAsyncWithPipesAndFds but with n_fds set to zero, so no FD assignments are used.

Executes a child program asynchronously (your program will not block waiting for the child to exit). The child program is specified by the only argument that must be provided, argv. argv should be a Nothing-terminated array of strings, to be passed as the argument vector for the child. The first string in argv is of course the name of the program to execute. By default, the name of the program must be a full path. If flags contains the SpawnFlagsSearchPath flag, the PATH environment variable is used to search for the executable. If flags contains the SpawnFlagsSearchPathFromEnvp flag, the PATH variable from envp is used to search for the executable. If both the SpawnFlagsSearchPath and SpawnFlagsSearchPathFromEnvp flags are set, the PATH variable from envp takes precedence over the environment variable. If the program name is not a full path and SpawnFlagsSearchPath flag is not used, then the program will be run from the current directory (or workingDirectory, if specified); this might be unexpected or even dangerous in some cases when the current directory is world-writable. On Windows, note that all the string or string vector arguments to this function and the other g_spawn*() functions are in UTF-8, the GLib file name encoding. Unicode characters that are not part of the system codepage passed in these arguments will be correctly available in the spawned program only if it uses wide character API to retrieve its command line. For C programs built with Microsoft's tools it is enough to make the program have a wmain() instead of main(). wmain() has a wide character argument vector as parameter. At least currently, mingw doesn't support wmain(), so if you use mingw to develop the spawned program, it should call g_win32_get_command_line() to get arguments in UTF-8. On Windows the low-level child process creation API CreateProcess() doesn't use argument vectors, but a command line. The C runtime library's spawn*() family of functions (which spawnAsyncWithPipes eventually calls) paste the argument vector elements together into a command line, and the C runtime startup code does a corresponding reconstruction of an argument vector from the command line, to be passed to main(). Complications arise when you have argument vector elements that contain spaces or double quotes. The spawn*() functions don't do any quoting or escaping, but on the other hand the startup code does do unquoting and unescaping in order to enable receiving arguments with embedded spaces or double quotes. To work around this asymmetry, spawnAsyncWithPipes will do quoting and escaping on argument vector elements that need it before calling the C runtime spawn() function. The returned childPid on Windows is a handle to the child process, not its identifier. Process handles and process identifiers are different concepts on Windows. envp is a Nothing-terminated array of strings, where each string has the form KEY=VALUE. This will become the child's environment. If envp is Nothing, the child inherits its parent's environment. flags should be the bitwise OR of any flags you want to affect the function's behaviour. The SpawnFlagsDoNotReapChild means that the child will not automatically be reaped; you must use a child watch (g_child_watch_add()) to be notified about the death of the child process, otherwise it will stay around as a zombie process until this process exits. Eventually you must call spawnClosePid on the childPid, in order to free resources which may be associated with the child process. (On Unix, using a child watch is equivalent to calling waitpid() or handling the SIGCHLD signal manually. On Windows, calling spawnClosePid is equivalent to calling CloseHandle() on the process handle returned in childPid). See g_child_watch_add(). Open UNIX file descriptors marked as FD_CLOEXEC will be automatically closed in the child process. SpawnFlagsLeaveDescriptorsOpen means that other open file descriptors will be inherited by the child; otherwise all descriptors except stdin/stdout/stderr will be closed before calling exec() in the child. SpawnFlagsSearchPath means that argv[0] need not be an absolute path, it will be looked for in the PATH environment variable. SpawnFlagsSearchPathFromEnvp means need not be an absolute path, it will be looked for in the PATH variable from envp. If both SpawnFlagsSearchPath and SpawnFlagsSearchPathFromEnvp are used, the value from envp takes precedence over the environment. SpawnFlagsChildInheritsStdin means that the child will inherit the parent's standard input (by default, the child's standard input is attached to /dev/null). SpawnFlagsStdinFromDevNull explicitly imposes the default behavior. Both flags cannot be enabled at the same time and, in both cases, the stdinPipeOut argument is ignored. SpawnFlagsStdoutToDevNull means that the child's standard output will be discarded (by default, it goes to the same location as the parent's standard output). SpawnFlagsChildInheritsStdout explicitly imposes the default behavior. Both flags cannot be enabled at the same time and, in both cases, the stdoutPipeOut argument is ignored. SpawnFlagsStderrToDevNull means that the child's standard error will be discarded (by default, it goes to the same location as the parent's standard error). SpawnFlagsChildInheritsStderr explicitly imposes the default behavior. Both flags cannot be enabled at the same time and, in both cases, the stderrPipeOut argument is ignored. It is valid to pass the same FD in multiple parameters (e.g. you can pass a single FD for both stdoutFd and stderrFd, and include it in sourceFds too). sourceFds and targetFds allow zero or more FDs from this process to be remapped to different FDs in the spawned process. If nFds is greater than zero, sourceFds and targetFds must both be non-Nothing and the same length. Each FD in sourceFds is remapped to the FD number at the same index in targetFds. The source and target FD may be equal to simply propagate an FD to the spawned process. FD remappings are processed after standard FDs, so any target FDs which equal stdinFd, stdoutFd or stderrFd will overwrite them in the spawned process. sourceFds is supported on Windows since 2.72. SpawnFlagsFileAndArgvZero means that the first element of argv is the file to execute, while the remaining elements are the actual argument vector to pass to the file. Normally spawnAsyncWithPipes uses argv[0] as the file to execute, and passes all of argv to the child. childSetup and userData are a function and user data. On POSIX platforms, the function is called in the child after GLib has performed all the setup it plans to perform (including creating pipes, closing file descriptors, etc.) but before calling exec(). That is, childSetup is called just before calling exec() in the child. Obviously actions taken in this function will only affect the child, not the parent. On Windows, there is no separate fork() and exec() functionality. Child processes are created and run with a single API call, CreateProcess(). There is no sensible thing childSetup could be used for on Windows so it is ignored and not called. If non-Nothing, childPid will on Unix be filled with the child's process ID. You can use the process ID to send signals to the child, or to use g_child_watch_add() (or waitpid()) if you specified the SpawnFlagsDoNotReapChild flag. On Windows, childPid will be filled with a handle to the child process only if you specified the SpawnFlagsDoNotReapChild flag. You can then access the child process using the Win32 API, for example wait for its termination with the WaitFor*() functions, or examine its exit code with GetExitCodeProcess(). You should close the handle with CloseHandle() or spawnClosePid when you no longer need it. If non-Nothing, the stdinPipeOut, stdoutPipeOut, stderrPipeOut locations will be filled with file descriptors for writing to the child's standard input or reading from its standard output or standard error. The caller of spawnAsyncWithPipes must close these file descriptors when they are no longer in use. If these parameters are Nothing, the corresponding pipe won't be created. If stdinPipeOut is Nothing, the child's standard input is attached to /dev/null unless SpawnFlagsChildInheritsStdin is set. If stderrPipeOut is NULL, the child's standard error goes to the same location as the parent's standard error unless SpawnFlagsStderrToDevNull is set. If stdoutPipeOut is NULL, the child's standard output goes to the same location as the parent's standard output unless SpawnFlagsStdoutToDevNull is set. error can be Nothing to ignore errors, or non-Nothing to report errors. If an error is set, the function returns False. Errors are reported even if they occur in the child (for example if the executable in @argv[0] is not found). Typically the message field of returned errors should be displayed to users. Possible errors are those from the G_SPAWN_ERROR domain. If an error occurs, childPid, stdinPipeOut, stdoutPipeOut, and stderrPipeOut will not be filled with valid values. If childPid is not Nothing and an error does not occur then the returned process reference must be closed using spawnClosePid. On modern UNIX platforms, GLib can use an efficient process launching codepath driven internally by posix_spawn(). This has the advantage of avoiding the fork-time performance costs of cloning the parent process address space, and avoiding associated memory overcommit checks that are not relevant in the context of immediately executing a distinct process. This optimized codepath will be used provided that the following conditions are met:

1. SpawnFlagsDoNotReapChild is set
2. SpawnFlagsLeaveDescriptorsOpen is set
3. SpawnFlagsSearchPathFromEnvp is not set
4. workingDirectory is Nothing
5. childSetup is Nothing
6. The program is of a recognised binary format, or has a shebang. Otherwise, GLib will have to execute the program through the shell, which is not done using the optimized codepath.

If you are writing a GTK application, and the program you are spawning is a graphical application too, then to ensure that the spawned program opens its windows on the right screen, you may want to use GdkAppLaunchContext, GAppLaunchContext, or set the DISPLAY environment variable. Since: 2.68

Deprecated: (Since version 2.70)Use spawnCheckWaitStatus instead, and check whether your code is conflating wait and exit statuses.

Set error if waitStatus indicates the child exited abnormally (e.g. with a nonzero exit code, or via a fatal signal). The spawnSync and g_child_watch_add() family of APIs return the status of subprocesses encoded in a platform-specific way. On Unix, this is guaranteed to be in the same format waitpid() returns, and on Windows it is guaranteed to be the result of GetExitCodeProcess(). Prior to the introduction of this function in GLib 2.34, interpreting waitStatus required use of platform-specific APIs, which is problematic for software using GLib as a cross-platform layer. Additionally, many programs simply want to determine whether or not the child exited successfully, and either propagate a GError or print a message to standard error. In that common case, this function can be used. Note that the error message in error will contain human-readable information about the wait status. The domain and code of error have special semantics in the case where the process has an "exit code", as opposed to being killed by a signal. On Unix, this happens if WIFEXITED() would be true of waitStatus. On Windows, it is always the case. The special semantics are that the actual exit code will be the code set in error, and the domain will be G_SPAWN_EXIT_ERROR. This allows you to differentiate between different exit codes. If the process was terminated by some means other than an exit status (for example if it was killed by a signal), the domain will be G_SPAWN_ERROR and the code will be SpawnErrorFailed. This function just offers convenience; you can of course also check the available platform via a macro such as G_OS_UNIX, and use WIFEXITED() and WEXITSTATUS() on waitStatus directly. Do not attempt to scan or parse the error message string; it may be translated and/or change in future versions of GLib. Prior to version 2.70, spawnCheckExitStatus provides the same functionality, although under a misleading name. Since: 2.70

On some platforms, notably Windows, the GPid type represents a resource which must be closed to prevent resource leaking. spawnClosePid is provided for this purpose. It should be used on all platforms, even though it doesn't do anything under UNIX.

A simple version of spawnAsync that parses a command line with shellParseArgv and passes it to spawnAsync. Runs a command line in the background. Unlike spawnAsync, the SpawnFlagsSearchPath flag is enabled, other flags are not. Note that SpawnFlagsSearchPath can have security implications, so consider using spawnAsync directly if appropriate. Possible errors are those from shellParseArgv and spawnAsync. The same concerns on Windows apply as for spawnCommandLineSync.

A simple version of spawnSync with little-used parameters removed, taking a command line instead of an argument vector. See spawnSync for full details. The commandLine argument will be parsed by shellParseArgv. Unlike spawnSync, the SpawnFlagsSearchPath flag is enabled. Note that SpawnFlagsSearchPath can have security implications, so consider using spawnSync directly if appropriate. Possible errors are those from spawnSync and those from shellParseArgv. If waitStatus is non-Nothing, the platform-specific status of the child is stored there; see the documentation of spawnCheckWaitStatus for how to use and interpret this. On Unix platforms, note that it is usually not equal to the integer passed to exit() or returned from main(). On Windows, please note the implications of shellParseArgv parsing commandLine. Parsing is done according to Unix shell rules, not Windows command interpreter rules. Space is a separator, and backslashes are special. Thus you cannot simply pass a commandLine containing canonical Windows paths, like "c:\program files\app\app.exe", as the backslashes will be eaten, and the space will act as a separator. You need to enclose such paths with single quotes, like "'c:\program files\app\app.exe' 'e:\folder\argument.txt'".

No description available in the introspection data.

No description available in the introspection data.