Hello all,
Is there anyway to open a pipe to a new process (On Unix)? You know, like popen in C. I have searched through the manual, but could not find anything there.
Thank you, Lam Luu
Afficher les réponses par date
On 14-Jun-09, at 10:59 AM, Lam Luu wrote:
Hello all,
Is there anyway to open a pipe to a new process (On Unix)? You know, like popen in C. I have searched through the manual, but could not find anything there.
Look for "open-process" in the manual. If your Gambit is properly installed, just do (help open-process).
Here is a simple example on Unix:
(read-line (open-process "date"))
"Sun Jun 14 13:07:57 EDT 2009"
Marc
On 14-Jun-09, at 1:09 PM, Marc Feeley wrote:
On 14-Jun-09, at 10:59 AM, Lam Luu wrote:
Hello all,
Is there anyway to open a pipe to a new process (On Unix)? You know, like popen in C. I have searched through the manual, but could not find anything there.
Look for "open-process" in the manual. If your Gambit is properly installed, just do (help open-process).
Here is a simple example on Unix:
(read-line (open-process "date"))
"Sun Jun 14 13:07:57 EDT 2009"
Although this works it is not usable in general because the process may not be reclaimed properly.
The latest patch to Gambit solves this problem by introducing new procedures: call-with-input-proces, with-input-from-process, etc. These procedures wait for the process to terminate (by calling process status). The patch also fixes a bug in process-status. So the example can be rewritten:
(with-input-from-process "date" read-line)
"Tue Jun 16 12:02:21 EDT 2009"
Marc
On 06/16/2009 11:03 AM, Marc Feeley wrote:
On 14-Jun-09, at 1:09 PM, Marc Feeley wrote:
On 14-Jun-09, at 10:59 AM, Lam Luu wrote:
Hello all,
Is there anyway to open a pipe to a new process (On Unix)? You know, like popen in C. I have searched through the manual, but could not find anything there.
Look for "open-process" in the manual. If your Gambit is properly installed, just do (help open-process).
Here is a simple example on Unix:
(read-line (open-process "date"))
"Sun Jun 14 13:07:57 EDT 2009"
Although this works it is not usable in general because the process may not be reclaimed properly.
The latest patch to Gambit solves this problem by introducing new procedures: call-with-input-proces, with-input-from-process, etc. These procedures wait for the process to terminate (by calling process status). The patch also fixes a bug in process-status. So the example can be rewritten:
(with-input-from-process "date" read-line)
"Tue Jun 16 12:02:21 EDT 2009"
Marc
So, for now, what can I do?
Thank you, Lam Luu
On 16-Jun-09, at 2:48 PM, Lam Luu wrote:
(with-input-from-process "date" read-line)
"Tue Jun 16 12:02:21 EDT 2009"
Marc
So, for now, what can I do?
Upgrade to the latest patches on the repository ("make update"). You could also define:
(define (with-input-from-process path-or-settings thunk) (let ((p (open-process path-or-settings))) (parameterize ((current-input-port p)) (let ((result (thunk))) (process-status p) (close-port p) result))))
Marc
On Tue, Jun 16, 2009 at 12:03:16PM -0400, Marc Feeley wrote:
The latest patch to Gambit solves this problem by introducing new procedures: call-with-input-proces, with-input-from-process, etc. These procedures wait for the process to terminate (by calling process status). The patch also fixes a bug in process-status.
Are these API expected to be relatively bug-free, or are they still considered experimental? I get an error when using them sometimes:
(let loop ((i 0)) (close-port (open-process (list path: "/bin/ls"))) (loop (+ i 1)))
*** ERROR IN loop, (console)@107.31 -- Interrupted system call (open-process '(path: "/bin/ls"))
Thanks,
On 18-Jun-09, at 10:57 AM, Taylor Venable wrote:
On Tue, Jun 16, 2009 at 12:03:16PM -0400, Marc Feeley wrote:
The latest patch to Gambit solves this problem by introducing new procedures: call-with-input-proces, with-input-from-process, etc. These procedures wait for the process to terminate (by calling process status). The patch also fixes a bug in process-status.
Are these API expected to be relatively bug-free, or are they still considered experimental? I get an error when using them sometimes:
(let loop ((i 0)) (close-port (open-process (list path: "/bin/ ls"))) (loop (+ i 1)))
*** ERROR IN loop, (console)@107.31 -- Interrupted system call (open-process '(path: "/bin/ls"))
I can't reproduce this bug on Mac OS X 10.5.6 using Gambit v4.4.4.
Please add some context:
1) On what OS? (give the output of: uname -a) 2) Using which version of Gambit (give the output of: gsi -v) 3) value of i when the problem occurs 4) number of files in the current directory
For the benefit of other users, you should post bug reports to http://www.iro.umontreal.ca/~gambit/bugzilla/
Marc
I glanced at some of the code in os-io.c. In every system call I looked at, if the system call fails with EINTR, Gambit will signal a Scheme error. This is almost certainly not what you want: for example, the delivery of SIGALRM may indicate that it's time to switch threads. If a system call fails with EINTR but nothing interesting happened, you generally want to restart the system call. Any system call may fail with EINTR. Not taking EINTR into account, and instead signalling errors just about every time a system call returns -1, will cause these random errors to show up, with different frequency under different operating systems.
Be careful, though, to actually check and handle events such as (Scheme) interrupts caused by (OS) signals, rather than simply restarting the system call on EINTR. If you just restart the system call on EINTR, one Scheme thread can hang all the others, for instance by trying to do a file operation on a slow NFS mount, or by trying to open a named fifo with no one on the other end. This is why you also don't want to set the SA_RESTART flag for all signals either (although it may be appropriate for some signals).
You are correct. EINTR is checked (in Scheme code) in a few critical places (like the read and write system calls), but all systems calls which can fail with EINTR should check it too. This might explain why the problem was not reported earlier.
Marc
On 18-Jun-09, at 12:34 PM, Taylor R Campbell wrote:
I glanced at some of the code in os-io.c. In every system call I looked at, if the system call fails with EINTR, Gambit will signal a Scheme error. This is almost certainly not what you want: for example, the delivery of SIGALRM may indicate that it's time to switch threads. If a system call fails with EINTR but nothing interesting happened, you generally want to restart the system call. Any system call may fail with EINTR. Not taking EINTR into account, and instead signalling errors just about every time a system call returns -1, will cause these random errors to show up, with different frequency under different operating systems.
Be careful, though, to actually check and handle events such as (Scheme) interrupts caused by (OS) signals, rather than simply restarting the system call on EINTR. If you just restart the system call on EINTR, one Scheme thread can hang all the others, for instance by trying to do a file operation on a slow NFS mount, or by trying to open a named fifo with no one on the other end. This is why you also don't want to set the SA_RESTART flag for all signals either (although it may be appropriate for some signals).
On Thu, Jun 18, 2009 at 11:41:46AM -0400, Marc Feeley wrote:
On 18-Jun-09, at 10:57 AM, Taylor Venable wrote:
On Tue, Jun 16, 2009 at 12:03:16PM -0400, Marc Feeley wrote:
The latest patch to Gambit solves this problem by introducing new procedures: call-with-input-proces, with-input-from-process, etc. These procedures wait for the process to terminate (by calling process status). The patch also fixes a bug in process-status.
Are these API expected to be relatively bug-free, or are they still considered experimental? I get an error when using them sometimes:
(let loop ((i 0)) (close-port (open-process (list path: "/bin/ls"))) (loop (+ i 1)))
*** ERROR IN loop, (console)@107.31 -- Interrupted system call (open-process '(path: "/bin/ls"))
I can't reproduce this bug on Mac OS X 10.5.6 using Gambit v4.4.4.
Please add some context:
- On what OS? (give the output of: uname -a)
- Using which version of Gambit (give the output of: gsi -v)
- value of i when the problem occurs
- number of files in the current directory
For the benefit of other users, you should post bug reports to http://www.iro.umontreal.ca/~gambit/bugzilla/
Sorry, I was uncertain whether it should even be considered a bug in light of the recent changes in this area, but it sounds like it must be. I'll post full details to the Bugzilla system, of course.