Hi,
Is
(defun foo () (let ((frame (make-application-frame 'climacs))) (clim-sys:make-process (lambda () (run-frame-top-level frame))) (execute-frame-command frame `(com-find-file "/tmp/foo.txt"))))
expected to be "safe"? At present, this is subject to a race condition, because the frame need not have been adopted properly by the time the execute-frame-command runs, and so it need not have a top-level sheet.
Would it be reasonable to guard against this in the branch of execute-frame-command, and if so, how? There's a symmetric case (which is probably less common) where the frame command is executed just after the top-level sheet is disowned.
Any ideas? It would be nice to support something along the lines of my FOO function above -- it seems like a natural expression of a response to user action.
Cheers,
Christophe
On 5/25/06, Christophe Rhodes csr21@cam.ac.uk wrote:
Hi,
Is
(defun foo () (let ((frame (make-application-frame 'climacs))) (clim-sys:make-process (lambda () (run-frame-top-level frame))) (execute-frame-command frame `(com-find-file "/tmp/foo.txt"))))
expected to be "safe"? At present, this is subject to a race condition, because the frame need not have been adopted properly by the time the execute-frame-command runs, and so it need not have a top-level sheet.
I still think this is a bad idea - the application thread may be running another command, or an event handler might be accessing the stream state or output history, and the usual thread safety problems can crop up. McCLIM could add a lock around command execution and locks on stream panes that would protect you 99.9% of the time (but still wouldn't solve your problem).
It might be a better idea to follow the suggestion made in the spec of queuing command events that can be executed in the main thread at its leisure (adding an enqueued-commands slot to the frame which the event handler for command events fills, and perhaps have read-frame-command first pull commands from that queue).
-
Andy Hefner -
Christophe Rhodes