Custom Query (1030 matches)

Many standard programs (many GNU tools, including GCC) produce output in UTF-8 or some other non-empty encoding. CCL::MONITOR-EXTERNAL-PROCESS just interprets each octet it receives as a character-code; ideally, there should be some way of specifying how those octets encode characters.

Non-interactive input to external processes sometimes involves writing a lisp stream's contents to a temporary file and passing a descriptor to that file as the subprocess' standard input; similarly, there should be some way of ensuring that that input is encoded according to the external program's expectations.

How significant a problem this is may depend on how visible it is, which in turn depends on lots of factors ("locales", terminal/Emacs settings) outside of the lisp's control. It seems desirable that the lisp offer a way of doing (its part of) this right.

If an existing output file is opened with :IF-EXISTS :SUPERSEDE in effect, OPEN renames the original file to a temporary file name. The code which tests for uniqueness of temporary file names is subject to race conditions (e.g., it is possible that two threads/processes could both conclude that the same temporary file name was available at about the same time and rename different files to the same temporary file name, clobbering at least one original.)

Some C library routines attempt to address this by making the test for availability be "open, creating and failing if the file exists". If everything which contends for the same pathname uses that method, that avoids conflicts. It might also be possible to minimize the possibility of collisions by incorporating a representation of process/thread IDs in the generated temporary filenames.

Any scheme which tries to handle this is only viable if all contenders use the same scheme.

This:

(gui:background-process-run-function "foo" (lambda () (print 123)))

consistently causes CCL to hang with a SBOD. This:

(gui:background-process-run-function "foo" (lambda () (sleep 1) (print 123)))

works reliably.