[rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking
On Sat, 14 Oct 2006 15:53:08 -0700, "Richard Fateman" <fateman@cs.berkeley.edu> wrote:
I think that's a problem related to the IDE and not to RDNZL. In LispWorks 5.0, for example, if I start the apropos example coming with RDNZL (which also uses Application.Run) with MP:PROCESS-RUN-FUNCTION as suggested in the RDNZL documentation it runs fine without locking the IDE, i.e. I can still use the listener or other graphical tools while the .NET window is up and interacting.
I just tried the Apropos example on Allegro... whether started off in an emacs buffer or a console window or an IDE debug window. In each environment, whether just typed in or within a (mp:process-run-function ...) the listener is locked..
OK, so I tried with Corman Lisp 3.0 (using CREATE-THREAD) - no problems, no locking, like with LispWorks. Maybe someone on this list can try the same with ECL, so we've covered all Lisps on Windows with MP capabilities.
I got a response from Charley Cox that suggests another route is needed around this, or I guess I will just have to consider changing my model of how to program.
Yeah, or you change your Lisp implementation... :)
I got a response from Charley Cox that suggests another route is needed around this, or I guess I will just have to consider changing my model of how to program.
Yeah, or you change your Lisp implementation... :)
It looks as if the foreign calls to .net are using the most conservative behavior, which is to block out all threads to protect the Lisp heap while the foreign call is active. If this restriction is not needed, then it should be a simple matter to remove it in port-acl.lisp. I will look into this and report back. Charley --- Charles A. Cox, Franz Inc. 555 12th Street, Suite 1450 Internet: cox@franz.com Oakland, CA 94607 WWW: http://www.franz.com/ Phone: (510) 452-2000; FAX: (510) 452-0182
On Sun, 15 Oct 2006 23:09:59 -0700, "Charles A. Cox" <cox@franz.com> wrote:
I got a response from Charley Cox that suggests another route is needed around this, or I guess I will just have to consider changing my model of how to program.
Yeah, or you change your Lisp implementation... :)
It looks as if the foreign calls to .net are using the most conservative behavior, which is to block out all threads to protect the Lisp heap while the foreign call is active. If this restriction is not needed, then it should be a simple matter to remove it in port-acl.lisp.
I will look into this and report back.
Great. Please note that I'll be away on vacation next week, so if you send patches after Thursday, I won't be able to make a new RDNZL release before November. Thanks, Edi.
Great. Please note that I'll be away on vacation next week, so if you send patches after Thursday, I won't be able to make a new RDNZL release before November.
The diffs below fix two areas: (1) clean up external-format initialization, and (2) enable rdnzl to run (as separate in-Lisp processes) without locking out the rest of Lisp. Edi, I didn't try to commit these changes even though I think I still may have write-access to the module on common-lisp.net. The diffs below are relative to a checkout done today. If you'd like me to submit the diffs in some other way, let me know. Charley ===== Begin diffs ===== Index: port-acl.lisp =================================================================== RCS file: /project/rdnzl/cvsroot/RDNZL/port-acl.lisp,v retrieving revision 1.6 diff -c -r1.6 port-acl.lisp *** port-acl.lisp 10 Aug 2006 15:36:47 -0000 1.6 --- port-acl.lisp 16 Oct 2006 21:25:44 -0000 *************** *** 61,67 **** (ash ,get-next-octet 8))))) ;; force auto-compilation. Suppress the unnecessary notes. ! (with-output-to-string (*standard-output*) (string-to-octets "foo" :external-format :rdnzl-fat)) (in-package :rdnzl) --- 61,67 ---- (ash ,get-next-octet 8))))) ;; force auto-compilation. Suppress the unnecessary notes. ! (with-output-to-string (*system-messages*) (string-to-octets "foo" :external-format :rdnzl-fat)) (in-package :rdnzl) *************** *** 144,149 **** --- 144,150 ---- (ff:def-foreign-call (,lisp-name ,c-name) ,(arg-spec arg-list) :returning ,(ffi-map-type result-type) :strings-convert t + :release-heap :when-ok :convention ':c) ,@(when (eq result-type 'ffi-wide-char) `((excl:fwrap ',lisp-name 'wchar_t-wrapper 'wchar_t-retval)))))) ===== End diffs ===== --- Charles A. Cox, Franz Inc. 555 12th Street, Suite 1450 Internet: cox@franz.com Oakland, CA 94607 WWW: http://www.franz.com/ Phone: (510) 452-2000; FAX: (510) 452-0182
On Mon, 16 Oct 2006 14:30:38 -0700, "Charles A. Cox" <cox@franz.com> wrote:
The diffs below fix two areas: (1) clean up external-format initialization, and (2) enable rdnzl to run (as separate in-Lisp processes) without locking out the rest of Lisp.
Thanks, I've released a new version which incorporates your patches.
Edi, I didn't try to commit these changes even though I think I still may have write-access to the module on common-lisp.net. The diffs below are relative to a checkout done today. If you'd like me to submit the diffs in some other way, let me know.
That's fine. Of course you still have write access, but the common-lisp.net CVS currently isn't in sync with my local CVS anyway: http://common-lisp.net/pipermail/rdnzl-devel/2006-September/000100.html Cheers, Edi.
Thanks, I've released a new version which incorporates your patches.
Thanks for the quick turnaround. Charley --- Charles A. Cox, Franz Inc. 555 12th Street, Suite 1450 Internet: cox@franz.com Oakland, CA 94607 WWW: http://www.franz.com/ Phone: (510) 452-2000; FAX: (510) 452-0182
participants (2)
-
Charles A. Cox -
Edi Weitz