From lavigne.eric at gmail.com Thu Sep 1 05:16:12 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Thu, 1 Sep 2005 05:16:12 +0000 Subject: [erlisp-devel] process-linking errors In-Reply-To: <43134761.1010204@dirkgerrits.com> References: <51e1bc300508290903ed9416@mail.gmail.com> <43134761.1010204@dirkgerrits.com> Message-ID: <51e1bc30050831221677b5282a@mail.gmail.com> I've written most of the code for process-linking, but I'm having some trouble with the function check-system-messages. When I compile it, I get lots of errors that I don't understand. When I run it, it continues indefinitely and slows my computer to a crawl. A little explanation about the 'checking-system-messages in process: If a user program tries to do a receive, Erlisp should check for system messages first so the user program doesn't see them. There's a problem with receive calling check-system-messages and also having check-system-messages calling receive because it tends to create infinite loops. My solution was to explicitely check for this circularity, so receive will only call check-system-messages if it was not called by check-system-messages. I have attached copies of the error messages and the modified source files (process.lisp and messaging.lisp). Hopefully someone has an idea what is going on. I will give this another try in the morning. Just one more day left for SoC, so I'm giving it one final push. Eric ================== in process.lisp ================== (defun check-system-messages () (setf (slot-value (current-process) 'checking-system-messages) t) (do ((msg (receive-with-matcher (cond-matcher m) ((and (consp m) (eq (first m) 'system)) (rest m)) ((:timeout 0) nil)) (receive-with-matcher (cond-matcher m) ((and (consp m) (eq (first m) 'system)) (rest m)) ((:timeout 0) nil)))) ((not msg) 'done) (when (consp msg) (cond ((and (eq (first msg) 'link-kill) (not (slot-value (current-process) 'dying))) (error "Linked process died. My turn.")) ((and (eq (first msg) 'link-request)) (reverse-link (second msg) :link-type (third msg)))))) (setf (slot-value (current-process) 'checking-system-messages) nil)) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: error_8-31.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: messaging.lisp Type: application/octet-stream Size: 5457 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: process.lisp Type: application/octet-stream Size: 6184 bytes Desc: not available URL: From metawilm at gmail.com Thu Sep 1 07:31:26 2005 From: metawilm at gmail.com (Willem Broekema) Date: Thu, 1 Sep 2005 09:31:26 +0200 Subject: [erlisp-devel] process-linking errors In-Reply-To: <51e1bc30050831221677b5282a@mail.gmail.com> References: <51e1bc300508290903ed9416@mail.gmail.com> <43134761.1010204@dirkgerrits.com> <51e1bc30050831221677b5282a@mail.gmail.com> Message-ID: On 9/1/05, Eric Lavigne wrote: > I've written most of the code for process-linking, but I'm having some > trouble with the function check-system-messages. When I compile it, I > get lots of errors that I don't understand. Eric, it seems that "receive-with-matcher" is a macro, and it was not loaded at the time you tried to compile the code. Therefore, the compiler thinks "r-w-m" is a regular function, and this form: ((and (consp m) (eq (first m) 'system)) (rest m)) is an argument for the function. Now, ((and ..) ..) is an invalid form as the car of the form must be the name of a function, macro or special form, but it is the list (and ..) instead. Therefore: ; ((AND # #) (REST M)) ; Error: Illegal function call. and the other errors are similar. - Willem From dirk at dirkgerrits.com Thu Sep 1 05:38:19 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 01 Sep 2005 07:38:19 +0200 Subject: [erlisp-devel] Description of pushed patches. Message-ID: <431693cb.ZBJgScYgyuecMSCN%dirk@dirkgerrits.com> openmcl-threads bryan d. o'connor **20050830025955 Modified threading procedures in compatibility.lisp to support OpenMCL. From dirk at dirkgerrits.com Thu Sep 1 05:40:19 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 01 Sep 2005 07:40:19 +0200 Subject: [erlisp-devel] openmcl patches In-Reply-To: <9BB720B4-230F-46F3-8DC4-56D7E7DDF788@lunch.org> References: <9BB720B4-230F-46F3-8DC4-56D7E7DDF788@lunch.org> Message-ID: <43169443.5070103@dirkgerrits.com> bryan o'connor wrote: > i've filled in the missing pieces in compatibility.lisp to > support openmcl. Nice, thank you. > all tests pass reliably except the test receive-with-timeout > occassionally runs a few milliseconds too long. Yeah that test isn't very good. I'm open for suggestions. > my darcs repo is here: > http://monday-monkey.com/repos/erlisp/ I've applied your openmcl related patch. If there are problems with it I hope you can help in solving them, because I have no Mac. Your SBCL 0.9.3 related patch is not enough to make that release work on my machine, but that might be a problem with my setup. I'll try to look into this. - Dirk From dirk at dirkgerrits.com Thu Sep 1 05:47:25 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 01 Sep 2005 07:47:25 +0200 Subject: [erlisp-devel] process-linking errors In-Reply-To: <51e1bc30050831221677b5282a@mail.gmail.com> References: <51e1bc300508290903ed9416@mail.gmail.com> <43134761.1010204@dirkgerrits.com> <51e1bc30050831221677b5282a@mail.gmail.com> Message-ID: <431695ED.7050502@dirkgerrits.com> Eric Lavigne wrote: > I've written most of the code for process-linking, but I'm having some > trouble with the function check-system-messages. When I compile it, I > get lots of errors that I don't understand. Willem Broekema diagnosed the problem correctly I think. You're using a macro from messaging.lisp in process.lisp, but process.lisp is loaded /before/ messaging.lisp. (See erlisp.asd.) And currently it /has/ to be this way, because messaging.lisp depends on stuff from process.lisp to be loaded before it itself is loaded. > When I run it, it continues indefinitely and slows my computer to a crawl. How can you run it if it doesn't compile? Anyway, maybe you could put CHECK-SYSTEM-MESSAGES in messaging.lisp for the time being? I'll have a more thorough look at your code later... - Dirk From dirk at dirkgerrits.com Thu Sep 1 05:54:26 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 01 Sep 2005 07:54:26 +0200 Subject: [erlisp-devel] openmcl patches In-Reply-To: <51e1bc3005082922095eabd8aa@mail.gmail.com> References: <9BB720B4-230F-46F3-8DC4-56D7E7DDF788@lunch.org> <51e1bc3005082922095eabd8aa@mail.gmail.com> Message-ID: <43169792.9010202@dirkgerrits.com> Eric Lavigne wrote: > If you can't find a way to improve the speed, it might be okay to submit > your changes as they stand. I've already put them in, because I don't see how his OpenMCL support is significantly more retarded then the current CMUCL or AllegroCL support. Busy waiting is a HUGE no-no. Also, the SBCL support doesn't work with SBCL 0.9.3 yet. Having this stuff in the repository at least allows people to play with it and send patches. I will *try* to do something about these this week. I've played a bit with AllegroCL's multiprocessing, and I have SBCL 0.9.3 installed now. But time is limited, as always. - Dirk From lavigne.eric at gmail.com Thu Sep 1 17:09:55 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Thu, 1 Sep 2005 10:09:55 -0700 Subject: [erlisp-devel] process-linking errors In-Reply-To: <431695ED.7050502@dirkgerrits.com> References: <51e1bc300508290903ed9416@mail.gmail.com> <43134761.1010204@dirkgerrits.com> <51e1bc30050831221677b5282a@mail.gmail.com> <431695ED.7050502@dirkgerrits.com> Message-ID: <51e1bc3005090110091b28ca9c@mail.gmail.com> > > When I run it, it continues indefinitely and >> slows my computer to a crawl. > > How can you run it if it doesn't compile? When I compile the rest of it and then paste that particular function into the REPL... I guess Willem's explanation shows why that worked. > > Anyway, maybe you could put CHECK-SYSTEM-MESSAGES in messaging.lisp for > the time being? I'll have a more thorough look at your code later... > Sounds like a good idea, but I will try to follow Far?'s suggestion and create a separate process monitor. As Far? pointed out, my solution was too complicated. Hopefully I will have time to work this evening. For now I am busy with school. Eric From dirk at dirkgerrits.com Thu Sep 1 17:33:18 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 01 Sep 2005 10:33:18 -0700 Subject: [erlisp-devel] process-linking errors In-Reply-To: <51e1bc3005090110091b28ca9c@mail.gmail.com> References: <51e1bc300508290903ed9416@mail.gmail.com> <43134761.1010204@dirkgerrits.com> <51e1bc30050831221677b5282a@mail.gmail.com> <431695ED.7050502@dirkgerrits.com> <51e1bc3005090110091b28ca9c@mail.gmail.com> Message-ID: <43173B5E.5070304@dirkgerrits.com> Eric Lavigne wrote: >>> When I run it, it continues indefinitely and slows my computer to >>> a crawl. >> >>How can you run it if it doesn't compile? > > > When I compile the rest of it and then paste that particular function > into the REPL... I guess Willem's explanation shows why that worked. Ah right. Hmm, so then why the crawling? Is that because of the busy waiting style of the messaging system then? That really needs to be addressed any way... I think this should do the trick for AllegroCL, but I can't try it out just now: (defun make-event () ... #+allegrocl (mp:make-gate nil) ...) (defun event-wait (event mutex) ;note: this function should appear inside with-mutex block ... #+allegro (progn (mp:process-wait "wait for message" #'mp:gate-open-p event) (mp:close-gate event)) ...) (defun event-notify (event) ... #+allegro (mp:open-gate event) ...) - Dirk From bryan-lisp at lunch.org Thu Sep 1 18:21:14 2005 From: bryan-lisp at lunch.org (bryan o'connor) Date: Thu, 1 Sep 2005 11:21:14 -0700 Subject: [erlisp-devel] openmcl patches In-Reply-To: <43169792.9010202@dirkgerrits.com> References: <9BB720B4-230F-46F3-8DC4-56D7E7DDF788@lunch.org> <51e1bc3005082922095eabd8aa@mail.gmail.com> <43169792.9010202@dirkgerrits.com> Message-ID: <624475E8-CEAD-4569-8C42-D32310D21166@lunch.org> > I've already put them in, because I don't see how his OpenMCL > support is > significantly more retarded then the current CMUCL or AllegroCL > support. > Busy waiting is a HUGE no-no. i reworked my openmcl-threads patch to use semaphores. my first pass was just blindly porting the allegro patches since openmcl's mp support started out very similar. this version is hopefully a little less revolting.. ;) darcs: http://monday-monkey.com/repos/erlisp/ ...bryan From dirk at dirkgerrits.com Thu Sep 1 18:39:13 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 01 Sep 2005 11:39:13 -0700 Subject: [erlisp-devel] openmcl patches In-Reply-To: <624475E8-CEAD-4569-8C42-D32310D21166@lunch.org> References: <9BB720B4-230F-46F3-8DC4-56D7E7DDF788@lunch.org> <51e1bc3005082922095eabd8aa@mail.gmail.com> <43169792.9010202@dirkgerrits.com> <624475E8-CEAD-4569-8C42-D32310D21166@lunch.org> Message-ID: <43174AD1.8080109@dirkgerrits.com> bryan o'connor wrote: > i reworked my openmcl-threads patch to use semaphores. > > my first pass was just blindly porting the allegro patches > since openmcl's mp support started out very similar. this > version is hopefully a little less revolting.. ;) Well it was no more revolting than the current CMUCL and AllegroCL backends. ;) > darcs: http://monday-monkey.com/repos/erlisp/ This seems a lot better, though I still can't test it. ;) That the following scenario can occur is a bit unfortunate though, but it's probably not a huge problem: * RECEIVE suspends the current process. * Another process sends N messages, so the semaphore is incremented by N. * The RECEIVEing process wakes up and decrements the semaphore by 1. All new messages since the last time are examined. Let's assume nothing matches. * The semaphore now still has a count of N-1, so instead of blocking immediately, the RECEIVEing process will do N-1 more checks (in vain) for newly arrived messages. BTW, that unlock/lock around wait-on-semaphore: good call. I forgot that in the AllegroCL code I posted earlier. (Though I guess I would have found out sooner or later. ;)) - Dirk From bryan-lisp at lunch.org Thu Sep 1 18:43:16 2005 From: bryan-lisp at lunch.org (bryan o'connor) Date: Thu, 1 Sep 2005 11:43:16 -0700 Subject: [erlisp-devel] process-linking errors In-Reply-To: <43173B5E.5070304@dirkgerrits.com> References: <51e1bc300508290903ed9416@mail.gmail.com> <43134761.1010204@dirkgerrits.com> <51e1bc30050831221677b5282a@mail.gmail.com> <431695ED.7050502@dirkgerrits.com> <51e1bc3005090110091b28ca9c@mail.gmail.com> <43173B5E.5070304@dirkgerrits.com> Message-ID: > I think this should do the trick for AllegroCL i tested it out with allegro 7.0 trial. just need to unlock the mutex first in event-wait. otherwise works similar to openmcl. i added it to my darcs repo. http://monday-monkey.com/repos/erlisp/ ...bryan > (defun make-event () > ... > #+allegrocl (mp:make-gate nil) > ...) > > (defun event-wait (event mutex) > ;note: this function should appear inside with-mutex block > ... > #+allegro (progn (mp:process-wait "wait for message" > #'mp:gate-open-p > event) > (mp:close-gate event)) > ...) > > (defun event-notify (event) > ... > #+allegro (mp:open-gate event) > ...) From dirk at dirkgerrits.com Thu Sep 1 18:45:12 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 01 Sep 2005 11:45:12 -0700 Subject: [erlisp-devel] process-linking errors In-Reply-To: References: <51e1bc300508290903ed9416@mail.gmail.com> <43134761.1010204@dirkgerrits.com> <51e1bc30050831221677b5282a@mail.gmail.com> <431695ED.7050502@dirkgerrits.com> <51e1bc3005090110091b28ca9c@mail.gmail.com> <43173B5E.5070304@dirkgerrits.com> Message-ID: <43174C38.6040804@dirkgerrits.com> bryan o'connor wrote: >> I think this should do the trick for AllegroCL > > > i tested it out with allegro 7.0 trial. just need to unlock > the mutex first in event-wait. Yes, my bad... > otherwise works similar to openmcl. > > i added it to my darcs repo. > http://monday-monkey.com/repos/erlisp/ Cool. I'll integrate it in the main Erlisp repository tonight. - Dirk >> (defun make-event () >> ... >> #+allegrocl (mp:make-gate nil) >> ...) >> >> (defun event-wait (event mutex) >> ;note: this function should appear inside with-mutex block >> ... >> #+allegro (progn (mp:process-wait "wait for message" >> #'mp:gate-open-p >> event) >> (mp:close-gate event)) >> ...) >> >> (defun event-notify (event) >> ... >> #+allegro (mp:open-gate event) >> ...) From lavigne.eric at gmail.com Fri Sep 2 00:41:46 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Fri, 2 Sep 2005 00:41:46 +0000 Subject: [erlisp-devel] receive Message-ID: <51e1bc30050901174172cfb163@mail.gmail.com> (setf msg (receive t)) Would this receive any available message and assign that message to msg? Eric From dirk at dirkgerrits.com Fri Sep 2 03:53:53 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 01 Sep 2005 20:53:53 -0700 Subject: [erlisp-devel] receive In-Reply-To: <51e1bc30050901174172cfb163@mail.gmail.com> References: <51e1bc30050901174172cfb163@mail.gmail.com> Message-ID: <4317CCD1.5070103@dirkgerrits.com> Eric Lavigne wrote: > (setf msg (receive t)) > > Would this receive any available message and assign that message to msg? (setf msg (receive-with-matcher (cond-matcher m) (t m))) should. - Dirk From lavigne.eric at gmail.com Fri Sep 2 04:11:05 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Fri, 2 Sep 2005 04:11:05 +0000 Subject: [erlisp-devel] receive In-Reply-To: <4317CCD1.5070103@dirkgerrits.com> References: <51e1bc30050901174172cfb163@mail.gmail.com> <4317CCD1.5070103@dirkgerrits.com> Message-ID: <51e1bc30050901211165b4e3f1@mail.gmail.com> > > (setf msg (receive t)) > > > > Would this receive any available message and assign that message to msg? > > (setf msg (receive-with-matcher (cond-matcher m) (t m))) > > should. > > - Dirk Thanks. I should be done programming process-linking in a few minutes. Then I just need to write up a couple tests before submitting. It has been frustrating throwing away the last few days of work, but Far?'s system-manager suggestion made things a lot simpler. Eric From lavigne.eric at gmail.com Fri Sep 2 05:10:35 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Fri, 2 Sep 2005 05:10:35 +0000 Subject: [erlisp-devel] Erlisp file loading order Message-ID: <51e1bc3005090122106f917b53@mail.gmail.com> I am running into another issue involving file loading order. node.lisp contains the following line: (defvar *current-node* (make-instance 'local-node)) Now that nodes are more than just an empty class (each node has a system-manager), there is a need to call functions while creating node instances (such as spawn). Is it okay to have circular dependencies in asdf? (:file "node" :depends-on ("package" "process")) (:file "process" :depends-on ("package" "mailbox" "node" "compatibility")) From dirk at dirkgerrits.com Thu Sep 1 20:18:11 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 01 Sep 2005 22:18:11 +0200 Subject: [erlisp-devel] Description of pushed patches. Message-ID: <43176203.iw+9pcyNpV4MedZ+%dirk@dirkgerrits.com> sbcl no longer supports (sb-thread:current-thread-id). bryan d. o'connor **20050830023327] openmcl-threads using semaphores. bryan d. o'connor **20050901181244] allegro-threads using gates. bryan d. o'connor **20050901235948 patch written by Dirk Gerrits. From lispnik at gmail.com Fri Sep 2 07:19:26 2005 From: lispnik at gmail.com (Ivan Boldyrev) Date: Fri, 02 Sep 2005 14:19:26 +0700 Subject: [erlisp-devel] Erlisp file loading order In-Reply-To: <51e1bc3005090122106f917b53@mail.gmail.com> (Eric Lavigne's message of "Fri, 2 Sep 2005 05:10:35 +0000") References: <51e1bc3005090122106f917b53@mail.gmail.com> Message-ID: On 9220 day of my life Eric Lavigne wrote: > I am running into another issue involving file loading order. > > node.lisp contains the following line: > (defvar *current-node* (make-instance 'local-node)) Note that it is runtime dependence, not compile-time. But it doesn't matter much. > Is it okay to have circular dependencies in asdf? No. In which order the files should be loaded? "node" cannot be loaded before "process" because it instantiate class defined later. "process" cannot be loaded before "node" because it depends on "node". I think you should move class definitions to separate file. Or join "node" and "process". -- Ivan Boldyrev Your bytes are bitten. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: From lavigne.eric at gmail.com Fri Sep 2 12:32:25 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Fri, 2 Sep 2005 12:32:25 +0000 Subject: [erlisp-devel] undefined-symbol Message-ID: <51e1bc3005090205325714b131@mail.gmail.com> I am confused by this error message. ; ; File: /root/erlisp/erlisp-cmucl/erlisp/src/manager.lisp ; In: DEFUN SYSTEM-MANAGER-PROCESS ; (RECEIVE-WITH-MATCHER (COND-MATCHER M) (T M)) ; Error: (during macroexpansion) ; Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER: the function LISTEN-TO-SYSTEM-MANAGER is undefined. ; ; Error: (during macroexpansion) ; Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER: the function LISTEN-TO-SYSTEM-MANAGER is undefined. ; ; Converted SYSTEM-MANAGER-PROCESS. It complains that function LISTEN-TO-SYSTEM-MANAGER is undefined, but you can see here that this undefined function is defined immediately before the function that complains about it being missing. It seems like everything I've tried over the last two days lead to some sort of missing function error, and this still doesn't make sense to me. When I write small Lisp codes on my own, it doesn't seem to matter in which order I define functions. As long as all the functions are defined before I start actually running the functions, everything just works. What is different here? Is symbol scope related to Excerpt from manager.lisp: (defun listen-to-system-manager () (when (slot-value (current-process) 'time-to-die) (suicide "System manager requested termination."))) (defun system-manager-process () (do ((msg (receive-with-matcher (cond-matcher m) (t m)) (receive-with-matcher (cond-matcher m) (t m)))) (nil) (cond ((eq 'link (first msg)) (setf (gethash (list (second msg) (third msg)) *link-table*) (fourth msg))) ((eq 'exit (first msg)) (maphash #'(lambda (k v) (let ((src (second msg)) (reason (third msg))) (when (member src k) (when (eq src (first k)) (cond ((or (eq v 'notify) (and (eq v 'default) (eq reason 'normal))) (send (second k) msg)) (t (kill-process (second k))))) (remhash k *link-table*)))) *link-table*))))) For reference, I have enclosed manager.lisp (new) and process.lisp (modified). Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: manager.lisp Type: application/octet-stream Size: 1917 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: process.lisp Type: application/octet-stream Size: 4510 bytes Desc: not available URL: From lavigne.eric at gmail.com Fri Sep 2 14:07:03 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Fri, 2 Sep 2005 10:07:03 -0400 Subject: [erlisp-devel] undefined-symbol In-Reply-To: References: <51e1bc3005090205325714b131@mail.gmail.com> Message-ID: <51e1bc30050902070728e6cb5d@mail.gmail.com> > > I am confused by this error message. > > > > ; > > ; File: /root/erlisp/erlisp-cmucl/erlisp/src/manager.lisp > > > > ; In: DEFUN SYSTEM-MANAGER-PROCESS > > > > ; (RECEIVE-WITH-MATCHER (COND-MATCHER M) (T M)) > > ; Error: (during macroexpansion) > > ; Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER: the function > > LISTEN-TO-SYSTEM-MANAGER is undefined. > > In the files you attached there was no call to this function, and as I > have not checked out the source I can't be sure, but apparently some > macro calls LISTEN-TO-SYSTEM-MANAGER during its expansion. Probably these calls occur in messaging.lisp. I forgot to include that file, and I won't have access to that computer again until tonight. Each process uses that function before send/receive to check whether it has orders to die. > > Now normally macroexpansion happens before functions are loaded. > Therefore a macro should normally expand without calling functions > (but may of course include function calls in the generated expansion > code). receive-with-matcher is a macro. listen-to-system-manager is called at the beginning of that macro. Instead, the macro should just be producing code that calls listen-... instead of calling listen-... and then producing code. I see my mistake now. > > When you really want to have a function to be available at > macro-expansion time, you have to wrap the function in eval-when, like > what now happens already with many functions in messaging.lisp: > > (eval-when (:compile-toplevel :load-toplevel :execute) > (defun LISTEN-... (..) ..) > ) > I don't need it at macro-expansion time. I was treating macros as though they were functions. This should be easy to fix now that I know what the problem is. Without seeing the function call, how did you figure out that I was calling that "missing function" from a macro? Eric From dirk at dirkgerrits.com Fri Sep 2 15:40:51 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Fri, 02 Sep 2005 08:40:51 -0700 Subject: [erlisp-devel] undefined-symbol In-Reply-To: <51e1bc30050902070728e6cb5d@mail.gmail.com> References: <51e1bc3005090205325714b131@mail.gmail.com> <51e1bc30050902070728e6cb5d@mail.gmail.com> Message-ID: <43187283.7000006@dirkgerrits.com> Eric Lavigne wrote: > Without seeing the function call, how did you figure out that I was > calling that "missing function" from a macro? The "Error: (during macroexpansion)" is a good clue, no? ;) - Dirk From dirk at dirkgerrits.com Fri Sep 2 15:44:55 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Fri, 02 Sep 2005 08:44:55 -0700 Subject: [erlisp-devel] Erlisp file loading order In-Reply-To: <51e1bc3005090122106f917b53@mail.gmail.com> References: <51e1bc3005090122106f917b53@mail.gmail.com> Message-ID: <43187377.9000006@dirkgerrits.com> Eric Lavigne wrote: > node.lisp contains the following line: > (defvar *current-node* (make-instance 'local-node)) > > Now that nodes are more than just an empty class (each node has a > system-manager), there is a need to call functions while creating node > instances (such as spawn). The variable *CURRENT-NODE* is not part of the API. (I know, it's hard to tell without a proper DEFPACKAGE form or documentation...) The function CURRENT-NODE is, part of the API, and you can just change it like this: (defvar *current-node* nil) (defun current-node () (when (null *current-node*) (setq *current-node* ...)) *current-node*) > Is it okay to have circular dependencies in asdf? Most definately not. The dependency graph undergoes a topological sort, and the resulting ordering is the order in which the files are loaded. With cycles in the graph, no topological ordering exists. - Dirk From metawilm at gmail.com Fri Sep 2 13:27:28 2005 From: metawilm at gmail.com (Willem Broekema) Date: Fri, 2 Sep 2005 15:27:28 +0200 Subject: [erlisp-devel] undefined-symbol In-Reply-To: <51e1bc3005090205325714b131@mail.gmail.com> References: <51e1bc3005090205325714b131@mail.gmail.com> Message-ID: On 9/2/05, Eric Lavigne wrote: > I am confused by this error message. > > ; > ; File: /root/erlisp/erlisp-cmucl/erlisp/src/manager.lisp > > ; In: DEFUN SYSTEM-MANAGER-PROCESS > > ; (RECEIVE-WITH-MATCHER (COND-MATCHER M) (T M)) > ; Error: (during macroexpansion) > ; Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER: the function > LISTEN-TO-SYSTEM-MANAGER is undefined. In the files you attached there was no call to this function, and as I have not checked out the source I can't be sure, but apparently some macro calls LISTEN-TO-SYSTEM-MANAGER during its expansion. Now normally macroexpansion happens before functions are loaded. Therefore a macro should normally expand without calling functions (but may of course include function calls in the generated expansion code). When you really want to have a function to be available at macro-expansion time, you have to wrap the function in eval-when, like what now happens already with many functions in messaging.lisp: (eval-when (:compile-toplevel :load-toplevel :execute) (defun LISTEN-... (..) ..) ) - Willem From fahree at gmail.com Thu Sep 15 22:57:02 2005 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Thu, 15 Sep 2005 18:57:02 -0400 Subject: [erlisp-devel] Fwd: [Sbcl-devel] async signals In-Reply-To: <200508301215.26536.mega@hotpop.com> References: <430A343E.4070603@fast.no> <200508301215.26536.mega@hotpop.com> Message-ID: <653bea160509151557388a4194@mail.gmail.com> I found this very interesting discussion on sbcl-devel. It shows the difficulty of doing things right if we are to kill processes asynchronously, yet they want to do things properly wrt catching them, ensuring atomicity of memory operations, freeing resources (notably alien data), etc. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Perhaps those of us who care about quality programs have not spoken up often enough -- `for bad programs to triumph requires only that good programmers remain silent.' I call this passivity the `Silence of the Lambdas.' -- hbaker ---------- Forwarded message ---------- From: G?bor Melis Date: 30-Aug-2005 06:15 Subject: Re: [Sbcl-devel] async signals To: Alexander Kjeldaas Cc: sbcl-devel at lists.sourceforge.net On Monday 22 August 2005 22:23, Alexander Kjeldaas wrote: > OPEN, CLOSE and other functions that need cleanup could assert that > *INTERRUPTS-ENABLED* is NIL. Thus unclean code could be weeded out. > > Maybe something like this: > > (let (x) > (unwind-protect-without-interrupts-in-cleanup > (progn > (setq-without-interrupts x (open ...)) > ...) > (when x (close x))))) > > would be easier to read? > > astor Yes, it's easier to read and within the bowels of sbcl it might even be utilized. Since async signals are not standard, people just don't expect arbitrary things to happen at any time. It's just hard. Something must be done to bend async signals into lisp. I thought about making serve-event check for pending interrupts. When a possibly blocking I/O call is made the user should be well prepared to handle arbitrary conditions anyway, right? Yeah, it is a bit of stretch. Especially considering that the caller needs to know exactly which calls can do I/O or call serve-event. Not likely, around methods and such make it even less so. At this point I got disheartened and come to think that abandoning a side-effecting computation (with-timeout, terminate-thread, C-c + abort) is practically unsafe wrt unwind-protect. With the exception of with-timeout they should not "normally" (not during development or as last resort) be used. Ordinary code is just full of assumptions of what can and cannot fail. That leaves us with some documentation to write and with-timeout. A quick audit on the paserve code base revealed that its need could be satisfied with: - deadlines on streams Currently, timeouts are per-operation. Sending one byte every timeout seconds is enough to keep a reader on the other end of the stream busy. For a web server, that has a stream for each request but performs multiple operations on the stream an upper limit for the sum of the duration of those operations is needed. (setf (stream-deadline stream) (+ 180 (get-universal-time))) (loop repeat 100 do (read-char stream)) A slight problem is clobbering deadlines already set. The following macro temporarily overwrites the deadline if the new deadline is earlier than the old one. (with-stream-deadline (stream (+ 5 (get-universal-time))) (read stream)) - a timeout on socket-connect, open (?), close The current implementation of with-timeout should work for aborting the system calls (connect, open). That would mean adding a :timeout parameter to socket-connect, and open on the lisp side. close with :abort t should not block, unless SO_LINGER is set. The plan: 1) implement a with-timeout that works with threads 2) add timeout parameters to socket-connect, open, ... (?) 3) implement stream deadlines Unfortunately, 1) needs a scheduler (like Zach's timer http://www.cliki.net/TIMER, 500 lines), but - on the bright side - it's still possible to implement with setitimer and does not require a dedicated thread. Please, flame this approach properly. Cheers, G?bor ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Sbcl-devel mailing list Sbcl-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sbcl-devel From fahree at gmail.com Thu Sep 15 22:57:56 2005 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Thu, 15 Sep 2005 18:57:56 -0400 Subject: [erlisp-devel] Fwd: [Sbcl-devel] async signals In-Reply-To: <200509151708.28339.mega@hotpop.com> References: <200508301215.26536.mega@hotpop.com> <200509151708.28339.mega@hotpop.com> Message-ID: <653bea1605091515574eb169de@mail.gmail.com> Next message by Gabor on same thread... [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] In reviewing the history of the English Government, its wars and its taxes, a bystander, not blinded by prejudice nor warped by interest, would declare that taxes were not raised to carry on wars, but that wars were raised to carry on taxes. -- Thomas Paine, "Rights of Man" ---------- Forwarded message ---------- From: G?bor Melis Date: 15-Sep-2005 11:08 Subject: Re: [Sbcl-devel] async signals To: sbcl-devel at lists.sourceforge.net Time flies. With #lisp becoming immune to async unwind, it's now sbcl-devil's time to think. The following might become part of the internals manual if the patch goes in, hence the repetition from earlier posts. * Issues with asynchronous unwinds (AUs) Consider the following example: (with-timeout 1 (let (fd) (unwind-protect (progn (setq fd (open ...)) ...) (when fd (close fd))))) There are several ways things can go wrong: ** (SETQ FD (OPEN ...)) can be interrupted and unwound just after OPEN returns but before SETQ is done ** foreign code may not like being aborted: imagine a Berkeley db update call in the second ..., it will not like being unwound in the middle ** cleanups may not be run: if the cleanup is interrupted it can be unwound without closing the fd ** AUs can clobber each other Suppose we have a thread that can be terminated cleanly: (defun greet () (unwind-protect (loop (write-line "Hello, world") (sleep 1)) (write-line "Good bye"))) (let ((thread (make-thread #'greet))) (sleep (random 6)) (terminate-thread thread)) So far so good. But what if two other threads try to terminate it at the same time? The second terminate can hit while the first unwinding is in still progress. This is not a problem since the target of the two throws is the same. Now, what happens if there is another AU with a different target? (defun greet-impatiently () (handler-case (sb-ext:with-timeout 3 (greet)) (sb-ext:timeout ()))) Let's try terminating it: (let ((thread (make-thread #'greet-impatiently))) (sleep (random 6)) (terminate-thread thread)) There are several possible outcomes, but the most interesting is when TERMINATE-THREAD starts unwinding then the timeout hits does another NLX to the HANDLER-CASE and the thread termination request is lost. Note that the UNWIND-PROTECT in GREET is not strictly needed for this scenario to occur. In general it is very hard to write reliable programs when multiple AUs play and can cancel or steer away (see http://www.lisp.org/HyperSpec/Issues/iss152-writeup.html) an ongoing unwind. * Implementation ** Interruption By definition an interruption is a function that is invoked asynchronously. ** AU unsafe zone A thread is said to be in AU unsafe zone iff execution is within a WITHOUT-ASYNCHRONOUS-UNWIND form, an UNWIND-PROTECT cleanup or it's unwinding. Note that there can be multiple simultaneous unwinds: (catch 'aaa (unwind-protect (throw 'aaa 'a) (catch 'bbb (throw 'bbb 'b)))) The implementation (on x86 only for the time being) keeps track of the outermost unwind-protect block that's being unwound to. If an AU occurs in an unsafe zone then the current AU handlers get to decide what happens. ** AU handlers Interruptions are run in a pretty normal dynamic environment with all the condition handlers that were setup in the thread. When an NLX occurs that leaves the interruption UNSAFE-ASYNCHRONOUS-UNWIND (a SERIOUS-CONDITION) is signalled if the interrupted thread is in an unsafe zone. Now if this condition was handled by the normal condition handlers a simple HANDLER-CASE for SERIOUS-CONDITION could unknowingly unwind the stack when it's unsafe. Hence, UNSAFE-ASYNCHRONOUS-UNWIND is signalled with a different set of condition handlers active. These handlers can be established by ASYNCHRONOUS-UNWIND-HANDLER-BIND or from within the interruption with PUSH-INTERRUPTION-UNWIND-HANDLERS, POP-INTERRUPTION-UNWIND-HANDLERS, the setfable INTERRUPTION-UNWIND-HANDLERS. (Bleh. I can see no way around this.) These handlers are run, protected by a WITHOUT-INTERRUPTS, when the interruption is about to be left (from an UNWIND-PROTECT cleanup around the interruption, in fact). The *only* restarts available are RETRY-LATER, ABORT (aborts the unwind) and CONTINUE (forces the unsafe unwind to continue). The AU handler may do an NLX by any of the usual suspects (THROW, RETURN-FROM, GO), but if it signals a condition only the AU handlers are there to help. Behind the scenes interruptions are run by INVOKE-INTERRUPTION that on a NLX from the interruption signals an UNSAFE-ASYNCHRONOUS-UNWIND (a SERIOUS-CONDITION). ** The RETRY-LATER restart The default AU handler invokes this restart. This is similar to the ABORT restart, but it sets up a timer to run the whole interruption again in a short time (~0.1s, randomized). Alternatively the implementation could poll for interruptions when the unsafe zone is potentially exited. This is not done since detecting unsafe zones is currently expensive, because the stack is searched for cleanup frames. ** Foreign code Foreign code is to be wrapped in WITHOUT-ASYNCHRONOUS-UNWIND by default. System calls are a different: they can be interrupted without ill effects. ** Examples Consider the slightly modified example: (with-timeout 1 (let (fd) (unwind-protect (progn (without-asynchronous-unwind () (setq fd (open ...))) ...) (when fd (close fd))))) This is bullet-proof wrt to open/close. The problems outlined above are gone: the fd cannot be lost by unwinding just after OPEN returns but before the SETQ is completed; the cleanup and CLOSE within it is guaranteed to run without much disturbance. But an unwind due to timeout cannot happen in the AU unsafe zones, and that means OPEN and maybe CLOSE should take a timeout argument. Also note that WITH-TIMEOUT doesn't work in cleanup forms (!), so this will not return in one second if CLOSE runs into problems: (unwind-protect ... (with-timeout 1 (close fd))) One can work around that by: (unwind-protect ... (asynchronous-unwind-handler-bind ((unsafe-asynchronous-unwind #'continue)) (with-timeout 1 (close fd)))) but more care is needed as it allows an ongoing unwind to be lost. * An alternative: double cross implementation It can be argued that an AU becomes a problem only if it would cross a WITHOUT-ASYNCHRONOUS-UNWIND, a cleanup, or cancel/steer away an ongoing unwind (i.e. it crosses an border of an interruption and an unsafe zone delimiter). Ultimately, it is about user expectations about what can go wrong and when. It's unclear if such a weakening of semantic the guarantees is worthwhile. In the above example if CLOSE has a HANDLER-CASE for ERROR then an AU can still make it fail without closing the fd. * TODO ** detection of cleanups is slow (walks the stack) ** detection of cleanups is racy And here is the patch: http://retes.hu/~mega/au.patch It has just reached a state where one can experiment with C-c-ing: (without-asynchronous-unwind () (sleep 5)) (unwind-protect t (sleep 5)) and get reasonable behaviour, so it must be ready for comments. Cheers, G?bor ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Sbcl-devel mailing list Sbcl-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sbcl-devel From lavigne.eric at gmail.com Fri Sep 16 23:32:36 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Fri, 16 Sep 2005 23:32:36 +0000 Subject: [erlisp-devel] broken process linking code In-Reply-To: <922570740.1126912463016.JavaMail.osg@osgjas03.cns.ufl.edu> References: <922570740.1126912463016.JavaMail.osg@osgjas03.cns.ufl.edu> Message-ID: <51e1bc30050916163263a6fa8c@mail.gmail.com> This is the process-linking code I wrote over the summer. It doesn't work, and classes keep me too busy to continue working on it right now. Hopefully someone will have time to fix it. Otherwise I will probably get back to it in a few months. The problem, most likely, is in messaging.lisp. I added calls to a new function at the beginning of send, receive, and receive-with-matcher, so that if a process were marked for destruction it would die before affecting other processes (thus the hook in send) and as soon as possible (thus the hooks in a couple other places). I didn't understand the macros that I was trying to modify, so I was not so surprised to get a bad result. Keeping the hook only in send might fix the problem, but that could be horribly inefficient depending on how often the process tries to send messages. There is also a need for a new test for process-linking. I vaguely remember writing at least a basic test, but there doesn't seem to be one in my working directory. manager.lisp most new code messaging.lisp hooks into old code created in send/receive/receive-with-matcher process.lisp "time-to-die" flag added to process class erlisp.asd new entry for manager.lisp -------------- next part -------------- A non-text attachment was scrubbed... Name: plinking.zip Type: application/octet-stream Size: 4993 bytes Desc: not available URL: From david.nospam.hopwood at blueyonder.co.uk Sat Sep 17 21:43:17 2005 From: david.nospam.hopwood at blueyonder.co.uk (David Hopwood) Date: Sat, 17 Sep 2005 22:43:17 +0100 Subject: [erlisp-devel] Re: Fwd: [Sbcl-devel] async signals In-Reply-To: <653bea160509151557388a4194@mail.gmail.com> References: <430A343E.4070603@fast.no> <200508301215.26536.mega@hotpop.com> <653bea160509151557388a4194@mail.gmail.com> Message-ID: <432C8DF5.1070003@blueyonder.co.uk> Far? wrote: > I found this very interesting discussion on sbcl-devel. It shows the > difficulty of doing things right if we are to kill processes > asynchronously, yet they want to do things properly wrt catching them, > ensuring atomicity of memory operations, freeing resources (notably > alien data), etc. In the case of shared memory concurrency, killing processes asynchronously is a minefield; it is so difficult to do right that IMO it should not be attempted. Fortunately, in an Erlang-like message passing language we don't have to deal with shared memory at the semantic level. The only effect that a process can have on other processes is by sending messages. That is: - sending a message is an atomic event, - the desired semantics of asynchronous termination is that all messages that the process attempts to send before a given point in its history are sent, and no messages that it attempts to send after that point are sent. Of course, given that we have to call code in libraries that do not just use pure message passing, implementing this model may be easier said than done. But at least it's a clean semantics to aim for. The specific reason why asynchronous termination is harder for a language using shared memory concurrency is that, if a thread is killed while it is holding a lock on an object, that object will still be accessible to other threads afterward. At best, the invariants of the object may be violated; at worst, the invariants of the language implementation may be violated, leading to loss of dynamic type safety. In a language using message passing concurrency, all objects are local to some process, and become inaccessible once that process is killed, so their state at that point does not matter. At the implementation level, it's probably not a good idea to attempt to kill threads at arbitrary points; they should only be killed at safe points. Some Lisp implementations may already have a suitable notion of safe point that is used for GC, for example. -- David Hopwood From fahree at gmail.com Sun Sep 18 00:26:38 2005 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Sat, 17 Sep 2005 17:26:38 -0700 Subject: [erlisp-devel] Re: async signals In-Reply-To: <432C8DF5.1070003@blueyonder.co.uk> References: <430A343E.4070603@fast.no> <200508301215.26536.mega@hotpop.com> <653bea160509151557388a4194@mail.gmail.com> <432C8DF5.1070003@blueyonder.co.uk> Message-ID: <653bea16050917172675673355@mail.gmail.com> On 9/17/05, David Hopwood wrote: > In the case of shared memory concurrency, killing processes asynchronously > is a minefield; it is so difficult to do right that IMO it should not be > attempted. Well, of course it shouldn't be done as is. But in as much as we're implementing an Erlang-like system on top of multithreaded Lisps, we precisely have to take into account such things. That's why a thread should only actually die at a safe point, which is a matter of checking a flag when (yield) is called -- and of course it should by the message system *before* any message is received. On the other hand, if SBCL does (eventually) provide ways to throw and safely catch asynchronous exceptions, there's no reason not to use them. > The specific reason why asynchronous termination is harder for a language > using shared memory concurrency is that, if a thread is killed while it is > holding a lock on an object, that object will still be accessible to other > threads afterward. At best, the invariants of the object may be violated; > at worst, the invariants of the language implementation may be violated, > leading to loss of dynamic type safety. I've formalized this phenomenon in my thesis :) This is why any higher-level concurrent language system must be able to define application invariants that the system will enforce. Erlang makes it possible by decomposing programs into linked processes. > At the implementation level, it's probably not a good idea to attempt to > kill threads at arbitrary points; they should only be killed at safe > points. > Some Lisp implementations may already have a suitable notion of safe point > that is used for GC, for example. Once again, THE SYSTEM-LEVEL NOTION OF SAFE POINT IS NOT THE APPLICATION-LEVEL NOTION OF SAFE POINT, and cannot possibly be you allow the internalization of user-defined atomicity constraints in the language. Erlang works around this in a clever way, rather than attempt to solve the problem. Or maybe, in a way, it *does* provide a solution, but it is unclear (to me) how this solution would be translated in terms of imperative programming with internal side-effects. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris. -- LarryWall, Programming Perl (1st edition) From lispnik at gmail.com Sun Sep 18 12:21:38 2005 From: lispnik at gmail.com (Ivan Boldyrev) Date: Sun, 18 Sep 2005 19:21:38 +0700 Subject: [erlisp-devel] Re: Fwd: [Sbcl-devel] async signals In-Reply-To: <432C8DF5.1070003@blueyonder.co.uk> (David Hopwood's message of "Sat, 17 Sep 2005 22:43:17 +0100") References: <430A343E.4070603@fast.no> <200508301215.26536.mega@hotpop.com> <653bea160509151557388a4194@mail.gmail.com> <432C8DF5.1070003@blueyonder.co.uk> Message-ID: On 9236 day of my life David Hopwood wrote: > In the case of shared memory concurrency, killing processes asynchronously > is a minefield; it is so difficult to do right that IMO it should not be > attempted. Un Unix-like (or POSIX-like) The only safe thing you can do during asynchronous interrupt handling is to read or set variable of some type sig_atomic_t. Doing anything else is opening can of worm. And it doesn't matter if it is shared memory concurrency or single-thread program: what if process receives yet another asynchronous signal in signal handler? It may corrupt variable you write to if it is other than sig_atomic_t. -- Ivan Boldyrev XML -- new language of ML family. From fahree at gmail.com Sun Sep 18 15:25:51 2005 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Sun, 18 Sep 2005 08:25:51 -0700 Subject: [erlisp-devel] Re: async signals In-Reply-To: References: <430A343E.4070603@fast.no> <200508301215.26536.mega@hotpop.com> <653bea160509151557388a4194@mail.gmail.com> <432C8DF5.1070003@blueyonder.co.uk> Message-ID: <653bea160509180825387fdcc5@mail.gmail.com> On 9/18/05, Ivan Boldyrev wrote: > Un Unix-like (or POSIX-like) The only safe thing you can do during > asynchronous interrupt handling is to read or set variable of some > type sig_atomic_t. Maybe you didn't realize that we were talking about Lisp and not C. Asynchronous interrupts at the Lisp level need not be asynchronous signals at the C level. Lisp interrupts can be either higher-level than the C level (already handling your sig_atomic_t and then doing something when back from the signal handler), or they can be lower-level (talking directly to the kernel, to avoid the limitations of the C library). And whatever level we are at, the problem of propagating asynchronous interrupts to the level above (that of the application -- which itself could be layered into many levels) is a non-trivial problem with essentially the same kind of solutions, only at a higher level. And the challenge for concurrent languages is PRECISELY to offer a way to deal with asynchronousness that deals nicely with the above problem. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] If a vegetarian eats vegetables, what does a humanitarian eat? -- Mark Twain From lispnik at gmail.com Mon Sep 19 14:58:38 2005 From: lispnik at gmail.com (Ivan Boldyrev) Date: Mon, 19 Sep 2005 21:58:38 +0700 Subject: [erlisp-devel] Re: async signals In-Reply-To: <653bea160509180825387fdcc5@mail.gmail.com> (fahree@gmail.com's message of "Sun, 18 Sep 2005 08:25:51 -0700") References: <430A343E.4070603@fast.no> <200508301215.26536.mega@hotpop.com> <653bea160509151557388a4194@mail.gmail.com> <432C8DF5.1070003@blueyonder.co.uk> <653bea160509180825387fdcc5@mail.gmail.com> Message-ID: On 9236 day of my life fahree at gmail.com wrote: > Maybe you didn't realize that we were talking about Lisp and not C. > Asynchronous interrupts at the Lisp level need not be asynchronous > signals at the C level. Lisp interrupts can be either higher-level > than the C level (already handling your sig_atomic_t and then doing > something when back from the signal handler), Then proper handling of sig_atomic_t is problem of Lisp system, not Lisp programmer. > or they can be lower-level (talking directly to the kernel, to avoid > the limitations of the C library). It's not limitation of C library, it is limitation of architecture. Layer of C library over signal API is too thin to limit something. No matter if you write you program in C, asm or Lisp, if processor can't write something atomically, you can't use it in async. interrupts. For example, no matter which language you use, you can't atomically write or read 64-bit integer (aka long long) with x86 platform. -- Ivan Boldyrev Outlook has performed an illegal operation and will be shut down. If the problem persists, contact the program vendor. From david.nospam.hopwood at blueyonder.co.uk Mon Sep 19 15:28:42 2005 From: david.nospam.hopwood at blueyonder.co.uk (David Hopwood) Date: Mon, 19 Sep 2005 16:28:42 +0100 Subject: [erlisp-devel] Re: async signals In-Reply-To: References: <430A343E.4070603@fast.no> <200508301215.26536.mega@hotpop.com> <653bea160509151557388a4194@mail.gmail.com> <432C8DF5.1070003@blueyonder.co.uk> <653bea160509180825387fdcc5@mail.gmail.com> Message-ID: <432ED92A.2090209@blueyonder.co.uk> Ivan Boldyrev wrote: > On 9236 day of my life fahree at gmail.com wrote: > >>or they can be lower-level (talking directly to the kernel, to avoid >>the limitations of the C library). > > It's not limitation of C library, it is limitation of architecture. > Layer of C library over signal API is too thin to limit something. It isn't particularly thin, and it certainly can be limiting. > No matter if you write you program in C, asm or Lisp, if processor can't > write something atomically, you can't use it in async. interrupts. > > For example, no matter which language you use, you can't atomically > write or read 64-bit integer (aka long long) with x86 platform. Bad example: 'lock cmpxchg8b'. -- David Hopwood From lispnik at gmail.com Mon Sep 19 15:57:35 2005 From: lispnik at gmail.com (Ivan Boldyrev) Date: Mon, 19 Sep 2005 22:57:35 +0700 Subject: [erlisp-devel] Re: async signals In-Reply-To: <653bea160509180825387fdcc5@mail.gmail.com> (fahree@gmail.com's message of "Sun, 18 Sep 2005 08:25:51 -0700") References: <430A343E.4070603@fast.no> <200508301215.26536.mega@hotpop.com> <653bea160509151557388a4194@mail.gmail.com> <432C8DF5.1070003@blueyonder.co.uk> <653bea160509180825387fdcc5@mail.gmail.com> Message-ID: On 9236 day of my life fahree at gmail.com wrote: > Maybe you didn't realize that we were talking about Lisp and not C. I thought a little more and I think we are both right :) -- Ivan Boldyrev Assembly of a Japanese bicycle requires greatest peace of spirit. From fahree at gmail.com Tue Sep 20 00:55:01 2005 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Mon, 19 Sep 2005 17:55:01 -0700 Subject: [erlisp-devel] Re: async signals In-Reply-To: References: <430A343E.4070603@fast.no> <200508301215.26536.mega@hotpop.com> <653bea160509151557388a4194@mail.gmail.com> <432C8DF5.1070003@blueyonder.co.uk> <653bea160509180825387fdcc5@mail.gmail.com> Message-ID: <653bea1605091917558be7d41@mail.gmail.com> On 9/19/05, Ivan Boldyrev wrote: > On 9236 day of my life fahree at gmail.com wrote: > > Maybe you didn't realize that we were talking about Lisp and not C. > > Asynchronous interrupts at the Lisp level need not be asynchronous > > signals at the C level. Lisp interrupts can be either higher-level > > than the C level (already handling your sig_atomic_t and then doing > > something when back from the signal handler), > > Then proper handling of sig_atomic_t is problem of Lisp system, not > Lisp programmer. > That's only the case if you're using C signals and wants to write in shared memory in C-multithreaded environment. A Lisp implementation may offer user-visible threads that have asynchronous interrupts at the lisp level and NOT USE ANY OF THE ABOVE AT ALL. And actually, that's what Erlang does and Erlisp could typically do: spawn one unix process per processor, each being the host of zillions of Erlang processes, that do not rely the least on either unix signals or unix shared memory for their internal asynchronous interrupts and communication. > It's not limitation of C library, it is limitation of architecture. The C library definitely does add limitations in terms of reentrancy, memory model, lack of PCLSRing, etc. There are few system calls you can do from a C signal handler, yet the kernel would happily oblige you on all of them. > Layer of C library over signal API is too thin to limit something. Bullshit. errno alone is enough to bring quite a lot of problems. > No > matter if you write you program in C, asm or Lisp, if processor can't > write something atomically, you can't use it in async. interrupts. You can't imagine that the async interrupts in Lisp don't have to be async interrupts in C. And you don't need your processor to write anything atomically if you're not actually using multiple concurrent processors, which won't happen if you have only one process and thread at the C level. > For example, no matter which language you use, you can't atomically > write or read 64-bit integer (aka long long) with x86 platform. 64-bit, you can actually (but then you'll tell me about some bigger size). However, it doesn't really matter what you can or cannot write atomically to shared memory, since the whole point of Erlisp is to avoid the shared memory model of concurrency. I grant you this: if we want to catch unix signals and send asynchronous interrupts of Erlisp processes from them, then whenever we call foreign C code that may be non-reentrant, we must wrap that code into a proper flag polling mechanism (which needn't be atomic since it's per-thread) that allows us to achieve PCLSRing by calling the rest of the signal handler when the thread is safely out of the potentially problematic C code. All this needn't apply when we're running "normal" code generated by a compiler we control, at which time you may use more hacking techniques for PCLSRing. [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Amateurs talk strategy. Professionals talk logistics. - old military saying From david.nospam.hopwood at blueyonder.co.uk Tue Sep 20 01:47:35 2005 From: david.nospam.hopwood at blueyonder.co.uk (David Hopwood) Date: Tue, 20 Sep 2005 02:47:35 +0100 Subject: [erlisp-devel] Re: async signals In-Reply-To: <653bea1605091917558be7d41@mail.gmail.com> References: <430A343E.4070603@fast.no> <200508301215.26536.mega@hotpop.com> <653bea160509151557388a4194@mail.gmail.com> <432C8DF5.1070003@blueyonder.co.uk> <653bea160509180825387fdcc5@mail.gmail.com> <653bea1605091917558be7d41@mail.gmail.com> Message-ID: <432F6A37.6030805@blueyonder.co.uk> Far? wrote: > On 9/19/05, Ivan Boldyrev wrote: > >>For example, no matter which language you use, you can't atomically >>write or read 64-bit integer (aka long long) with x86 platform. > > 64-bit, you can actually (but then you'll tell me about some bigger size). > However, it doesn't really matter what you can or cannot write atomically > to shared memory, since the whole point of Erlisp is to avoid the shared > memory model of concurrency. OTOH, there are some very efficient lock-free implementations of message queues that you can use if pointer-sized words can be written atomically. But all multiprocessor platforms can do that. -- David Hopwood