From root at common-lisp.net Mon May 8 06:00:31 2006 From: root at common-lisp.net (root) Date: Mon, 8 May 2006 02:00:31 -0400 (EDT) Subject: [cl-muproc-devel] Auto-nag: cl-muproc please update your webpage Message-ID: <20060508060031.C6EFF2000F@common-lisp.net> You are being nagged on because you have not created a sensible default webpage for your project. Please do so or you will be nagged again next week. All we ask is that you type in something about the project and perhaps some links to mailinglists etc. See common-lisp.net/project/clo/sp/index.html for a reasonable template. Some projects host their webpages somewhere else (eg. http://common-lisp.net/project/cl-ppcre) and if you're in the same situation you may put the following in your index.shtml: Any questions? You can reach the author of this cronjob at clo-devel at common-lisp.net Thanks! From klaus at mu.dk Mon May 8 19:46:08 2006 From: klaus at mu.dk (Klaus Harbo) Date: Mon, 08 May 2006 21:46:08 +0200 Subject: [cl-muproc-devel] Test posting Message-ID: <445FA000.9010409@mu.dk> Testing, testing -- 1,2,3... From klaus at mu.dk Mon May 8 19:48:18 2006 From: klaus at mu.dk (Klaus Harbo) Date: Mon, 08 May 2006 21:48:18 +0200 Subject: [cl-muproc-devel] Testing Message-ID: <445FA082.5030305@mu.dk> Testing -- 1,2,3... From klaus at mu.dk Sun May 14 08:06:02 2006 From: klaus at mu.dk (Klaus Harbo) Date: Sun, 14 May 2006 10:06:02 +0200 Subject: [cl-muproc-devel] First publically available incarnation of CL-MUPROC released: cl-muproc--2006-05-14 Message-ID: <4466E4EA.3090104@mu.dk> I am pleased to announce that CL-MUPROC is now available at http://www.common-lisp.net/project/cl-muproc. As you will see, the reference documentation is far from complete; only the core functionality is documented at this time. Please do feel free to try it out and offer any feed-back, comments, suggestions, or whatever (patches, even! ;-). Enjoy! -Klaus Harbo From billclem at gmail.com Sun May 14 23:08:23 2006 From: billclem at gmail.com (Bill Clementson) Date: Sun, 14 May 2006 16:08:23 -0700 Subject: [cl-muproc-devel] First publically available incarnation of CL-MUPROC released: cl-muproc--2006-05-14 In-Reply-To: <4466E4EA.3090104@mu.dk> References: <4466E4EA.3090104@mu.dk> Message-ID: <8757cb490605141608g56d8efacmc41f47671a9bd878@mail.gmail.com> Hi Klaus, > I am pleased to announce that CL-MUPROC is now available at > http://www.common-lisp.net/project/cl-muproc. As you will see, the > reference documentation is far from complete; only the core > functionality is documented at this time. > > Please do feel free to try it out and offer any feed-back, comments, > suggestions, or whatever (patches, even! ;-). There is a minor typo in the source for supervisor.lisp (patch below) that causes a compile error. I'm looking forward to trying out the code later. - Bill *** /Users/bc/lisp/unstable/cl-muproc--2006-05-14/supervisor.lisp~ Sun May 14 00:47:06 2006 --- /Users/bc/lisp/unstable/cl-muproc--2006-05-14/supervisor.lisp Sun May 14 13:28:59 2006 *************** *** 424,430 **** ch)) ;;; STATE ! :;; ============================================================================ (defgeneric current-state (sn) (:method ((vs supervisee)) --- 424,430 ---- ch)) ;;; STATE ! ;;; ============================================================================ (defgeneric current-state (sn) (:method ((vs supervisee)) From klaus at mu.dk Mon May 15 03:53:51 2006 From: klaus at mu.dk (Klaus Harbo) Date: Mon, 15 May 2006 05:53:51 +0200 Subject: [cl-muproc-devel] Re: [ann] [cl-muproc-announce] First publically available incarnation of CL-MUPROC released: cl-muproc--2006-05-14 In-Reply-To: References: <4466E63C.9000904@mu.dk> Message-ID: <4467FB4F.2030305@mu.dk> Gary King wrote: > Hi Klaus, > > This looks great. I've not looked at the code enough to know whether > or not it makes sense but it may be that Dan Corkill's portable > threads library will make it easier to bring this to other lisps. > Portable-threads is on the CLiki and is ASDf-Installable. > > keep peace, > > > --Gary Warren King > metabang.com > http://www.metabang.com/ > (413) 210 7511 > gwking on #lisp (occasionally) > > Hi Gary -- I admit I haven't heard of this library; but I will take a look at it. My plan until now has been to go with acl-compat as the compatibility layer. -Klaus. From rudi at constantly.at Mon May 15 10:42:56 2006 From: rudi at constantly.at (Rudi Schlatte) Date: Mon, 15 May 2006 12:42:56 +0200 Subject: [cl-muproc-devel] First publically available incarnation of CL-MUPROC released: cl-muproc--2006-05-14 In-Reply-To: <4467FB4F.2030305@mu.dk> References: <4466E63C.9000904@mu.dk> <4467FB4F.2030305@mu.dk> Message-ID: On 15. Mai 2006, at 05:53, Klaus Harbo wrote: > Gary King wrote: >> Hi Klaus, >> >> This looks great. I've not looked at the code enough to know >> whether or not it makes sense but it may be that Dan Corkill's >> portable threads library will make it easier to bring this to >> other lisps. Portable-threads is on the CLiki and is ASDf- >> Installable. >> > > I admit I haven't heard of this library; but I will take a look at > it. My plan until now has been to go with acl-compat as the > compatibility layer. > There's already muproc-compat.lisp that encapsulates all implementation-dependent functionality; it might not be necessary to introduce another compatibility layer. I briefly looked at portable- threads and it doesn't seem to have an equivalent to Lispworks' mailbox inter-thread communication mechanism, so we will have to implement this by hand anyway. Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From js at codeartist.org Tue May 16 10:37:31 2006 From: js at codeartist.org (Jochen Schmidt) Date: Tue, 16 May 2006 12:37:31 +0200 Subject: [cl-muproc-devel] Some suggestions Message-ID: <9F208920-F9A7-440C-B889-C99FEC8C4490@codeartist.org> Hello, First I want to thank for making available CL-MUPROC; I think that Erlang style concurrency is a very interesting and valuable addition to Common Lisp. Some people have already pointed out that CL-MUPROCS process implementation is to heavy-weight for Erlang style concurrency. While I think that this is true, I do not see it as a big problem. Even if CL-MUPROC will not get such more scalable process implementations it will be a good API for doing multiprocessing in CL (instead of using the MP facilities of the different Lisps directly). I personally think that the muproc-* prefixes are unnecessary. Particularily names like MUPROCS-SEND or MUPROCS-RECEIVE might be better spelled MUPROCS:SEND or MUPROCS:RECEIVE with the option to import this symbols into an application package and then just use SEND and RECEIVE. Using packages this way would also enable to use your own prefixes by just adding appropriate nicknames to the MUPROCS package (MU:SEND, MU:RECEIVE). ciao, Jochen From klaus at mu.dk Tue May 16 18:13:28 2006 From: klaus at mu.dk (Klaus Harbo) Date: Tue, 16 May 2006 20:13:28 +0200 Subject: [cl-muproc-devel] Some suggestions In-Reply-To: <9F208920-F9A7-440C-B889-C99FEC8C4490@codeartist.org> References: <9F208920-F9A7-440C-B889-C99FEC8C4490@codeartist.org> Message-ID: <446A1648.4060906@mu.dk> Jochen Schmidt wrote: > Hello, > > First I want to thank for making available CL-MUPROC; I think that > Erlang style concurrency is a very interesting and valuable addition > to Common Lisp. Some people have already pointed out that CL-MUPROCS > process implementation is to heavy-weight for Erlang style > concurrency. While I think that this is true, I do not see it as a big > problem. Even if CL-MUPROC will not get such more scalable process > implementations it will be a good API for doing multiprocessing in CL > (instead of using the MP facilities of the different Lisps directly). I agree on both points. However, I think there are real implications of not being able to spawn as my muprocs as you like. In Erlang, you can realistically design a system which spawns a process for each task the system needs to handle. In cl-muproc, if you're concerned with scalability of your design, that is not a viable approach. You have to think differently; at least that's what I have been doing. The system we're building, I have stayed with a static number number of muprocs and use finite state machines inside muprocs to scale task-wise. This approach has worked quite well, I think, although I would really like to have the scale-by-spawning option available as well. Unfortunately, to my knowledge no Lisp implementation can offer really large numbers of threads. I have experimented at little bit -- Allegro has a hard-coded limit of a few hundred processes/threads (I forget what term they use), Lispworks starts slowing down something awful on my AMD64 machine once you have spawned some 500 threads or so. > > I personally think that the muproc-* prefixes are unnecessary. > Particularily names like MUPROCS-SEND or MUPROCS-RECEIVE might be > better spelled MUPROCS:SEND or MUPROCS:RECEIVE with the option to > import this symbols into an application package and then just use SEND > and RECEIVE. Using packages this way would also enable to use your own > prefixes by just adding appropriate nicknames to the MUPROCS package > (MU:SEND, MU:RECEIVE). > I know what you mean. Actually, I do not have strong feelings on this point, except that I think it is an issue of balancing 'name space clutter' against long names. Personally, I like to import exported symbols of the libraries/packages I use into my own packages. Obviously, I don't want them to clash with symbols from other packages. When I started muproc I simply had 'send' and 'receive' (which are now mumsg-send and mumsg-receive, btw), but at some point I felt that these terms were pretty generic, and that the danger of clashes with other libraries was large enough to consider. To be a 'good Lisp citizen' I felt that muproc shouldn't claim that piece of name space for itself, so I decided that muproc-send and muproc-receive (and subsequently mumsg-ditto) would be better, and for consistency that other exported symbols should have appropriately prefixed names as well. However, if consensus is that eliminating the prefixes is preferable, I could certainly live with that as well. I am certainly susceptible to the argument that muproc:send is not much more typing than muproc-send! ;-) > ciao, > Jochen -Klaus. From js at codeartist.org Tue May 16 21:53:52 2006 From: js at codeartist.org (Jochen Schmidt) Date: Tue, 16 May 2006 23:53:52 +0200 Subject: [cl-muproc-devel] Some suggestions In-Reply-To: <446A1648.4060906@mu.dk> References: <9F208920-F9A7-440C-B889-C99FEC8C4490@codeartist.org> <446A1648.4060906@mu.dk> Message-ID: <0DACDABC-57DB-43DE-89C3-9F53EDFC3893@codeartist.org> Am 16.05.2006 um 20:13 schrieb Klaus Harbo: > Jochen Schmidt wrote: >> Hello, >> >> First I want to thank for making available CL-MUPROC; I think that >> Erlang style concurrency is a very interesting and valuable >> addition to Common Lisp. Some people have already pointed out that >> CL-MUPROCS process implementation is to heavy-weight for Erlang >> style concurrency. While I think that this is true, I do not see >> it as a big problem. Even if CL-MUPROC will not get such more >> scalable process implementations it will be a good API for doing >> multiprocessing in CL (instead of using the MP facilities of the >> different Lisps directly). > I agree on both points. However, I think there are real > implications of not being able to spawn as my muprocs as you like. > In Erlang, you can realistically design a system which spawns a > process for each task the system needs to handle. In cl-muproc, if > you're concerned with scalability of your design, that is not a > viable approach. You have to think differently; at least that's > what I have been doing. The system we're building, I have stayed > with a static number number of muprocs and use finite state > machines inside muprocs to scale task-wise. This approach has > worked quite well, I think, although I would really like to have > the scale-by-spawning option available as well. Unfortunately, to > my knowledge no Lisp implementation can offer really large numbers > of threads. I have experimented at little bit -- Allegro has a > hard-coded limit of a few hundred processes/threads (I forget what > term they use), Lispworks starts slowing down something awful on my > AMD64 machine once you have spawned some 500 threads or so. I imagine how worker-thread scheduling is done in allegroserve and I think it would look alot better using an API like CL-MUPROC. >> I personally think that the muproc-* prefixes are unnecessary. >> Particularily names like MUPROCS-SEND or MUPROCS-RECEIVE might be >> better spelled MUPROCS:SEND or MUPROCS:RECEIVE with the option to >> import this symbols into an application package and then just use >> SEND and RECEIVE. Using packages this way would also enable to use >> your own prefixes by just adding appropriate nicknames to the >> MUPROCS package (MU:SEND, MU:RECEIVE). >> > I know what you mean. Actually, I do not have strong feelings on > this point, except that I think it is an issue of balancing 'name > space clutter' against long names. Personally, I like to import > exported symbols of the libraries/packages I use into my own > packages. Obviously, I don't want them to clash with symbols from > other packages. Well - this is what packages are made for: avoiding symbol-name clashes I personally make a distinction between implementation packages and interface packages. In implementation packages I collect the symbols of different interface packages to implement a particular module. The symbols of the interface of the module itself are imported too from a separate interface package. Some macrology and package hacking makes this all a quite straightforward job. > When I started muproc I simply had 'send' and 'receive' (which are > now mumsg-send and mumsg-receive, btw), but at some point I felt > that these terms were pretty generic, and that the danger of > clashes with other libraries was large enough to consider. To be a > 'good Lisp citizen' I felt that muproc shouldn't claim that piece > of name space for itself, so I decided that muproc-send and muproc- > receive (and subsequently mumsg-ditto) would be better, and for > consistency that other exported symbols should have appropriately > prefixed names as well. However, if consensus is that eliminating > the prefixes is preferable, I could certainly live with that as > well. I am certainly susceptible to the argument that muproc:send > is not much more typing than muproc-send! ;-) But MU:SEND or even M:SEND is significantly shorter! :-) Quite a while ago I was used to use class prefixes in all generic functions after reading http://cybertiggyr.com/gene/www.lisp-p.org/ htdocs/80-closminded/ I decided to drop the prefixes on accessors and on generic functions. ciao, Jochen From klaus at mu.dk Wed May 17 20:16:51 2006 From: klaus at mu.dk (Klaus Harbo) Date: Wed, 17 May 2006 22:16:51 +0200 Subject: [cl-muproc-devel] New version of cl-muproc: more documentation Message-ID: <446B84B3.107@mu.dk> A new version of cl-muproc is available -- a bit more documentation added. -Klaus. From rudi at constantly.at Wed May 17 21:43:58 2006 From: rudi at constantly.at (Rudi Schlatte) Date: Wed, 17 May 2006 23:43:58 +0200 Subject: [cl-muproc-devel] New version of cl-muproc: more documentation In-Reply-To: <446B84B3.107@mu.dk> References: <446B84B3.107@mu.dk> Message-ID: <642F5F52-DC97-444E-8060-B7F7AB3AD6E0@constantly.at> On 17. Mai 2006, at 22:16, Klaus Harbo wrote: > A new version of cl-muproc is available -- a bit more documentation > added. Cool, thanks. I'm in the process of implementing mailboxes on OpenMCL, at the moment investigating how to do condition variables. (There's some code by Gary Byers doing similar things in the guts of Portable AllegroServe, so it shouldn't take too long.) It's slow going only because work keeps me busy at the moment. Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From js at codeartist.org Thu May 18 05:39:02 2006 From: js at codeartist.org (Jochen Schmidt) Date: Thu, 18 May 2006 07:39:02 +0200 Subject: [cl-muproc-devel] Some suggestions In-Reply-To: <446B6A23.2050400@mu.dk> References: <9F208920-F9A7-440C-B889-C99FEC8C4490@codeartist.org> <446A1648.4060906@mu.dk> <0DACDABC-57DB-43DE-89C3-9F53EDFC3893@codeartist.org> <446B6A23.2050400@mu.dk> Message-ID: Am 17.05.2006 um 20:23 schrieb Klaus Harbo: > Package names as short as MU or M moved the name space clutter into > the package name space instead, so I see some problems following > that particular path (also, since I work for a company called Mu, I > think we'll find the name MU less than descriptive!). We'll run > out of single-letter package names very quickly indeed. > > I do not want to rule out the idea of getting rid of the muproc- > prefix from the names of the exported symbols in cl-muproc; at the > same time it does not strike me as a very high priority item. > Also, it seems to me that such a change would mean that it may be > difficult to import muproc symbols into user packages, due to - > potentially - name clashes. This would mean using 'muproc:send' > instead of 'muproc-send', so I wonder, then, what we have > accomplished? (Unless if we choose to go with Jochen's supershort > package names, which I do not think is a great idea). I may have explained my point a bit to fuzzy - I did not mean to suggest to rename the package to something very short like M or MU - better make it longer DK.MU.MUPROC or whatever to make it unique. Then use (in-package :dk.mu.muproc) everywhere in CL-MUPROC. A _user_ of CL-MUPROC can then decide to: 1) Import all exported symbols of CL-MUPROC using USE-PACKAGE in his application package 2) Import only a small selection of symbols of CL-MUPROC in his application package 3) Import all but shadow some CL-MUPROC or other symbols 4) Just use DK.MU.MUPROC:SEND or perhaps the provided nickname MUPROC:SEND. 5) Define his own nickname MU:SEND or ERL:SEND or M:SEND whatever he wants in the scope of his application 6) Use something like CL-PACKAGE-ALIASES (http://www.cliki.net/cl- package-aliases) or hierarchical packages to create short package- name aliases within a particular package. So: using packages provides a choice that is unavailable if one uses hardcoded prefixes. I hope this made the intention behind my suggestion a bit clearer, Jochen From rudi at constantly.at Thu May 25 10:24:44 2006 From: rudi at constantly.at (Rudi Schlatte) Date: Thu, 25 May 2006 12:24:44 +0200 Subject: [cl-muproc-devel] [Patch] Reorganisation of impl-dependent functions: proposal Message-ID: <6E2AC665-29E5-48F8-80D4-2EC7C317A2B6@constantly.at> Hello all, Thanks to the good work of Klaus, cl-muproc already has a good separation of core functions and implementation-dependent code. There is no explicit dependence on lispworks anywhere except muproc- compat.lisp[1], so porting to other implementations should be easy. In order to keep things tidy, I propose to gather each implementation's code into its own file. The attached patch implements this for lispworks. The patch also removes the dependency upon acl-compat. The rationale is two-fold: - some implementation-dependent code is necessary anyway, because acl- compat does not implement lispworks-style mailboxes (nor condition- variables, upon which mailboxes can be built). - acl-compat pulls in cl-ppcre and puri, two libraries that are completely unrelated to multiprocessing. With this patch, starting a new port would consist of: - copying muproc-compat.lisp to muproc-.lisp - adding the file to cl-muproc.asd - implementing the stub functions in muproc-.lisp I feel this is a better solution than adding to an ever-expanding muproc-compat.lisp. Cheers, Rudi [1] The implicit dependence is without-scheduling, which presupposes the scheduler is under control of the Lisp runtime. The last time I looked at that part of the code in depth (on the train ride back from Hamburg), I felt confident that the code without-scheduling could be rewritten without it. -------------- next part -------------- A non-text attachment was scrubbed... Name: muproc-compat.patch Type: application/octet-stream Size: 25364 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From klaus at mu.dk Mon May 29 09:07:02 2006 From: klaus at mu.dk (Klaus Harbo) Date: Mon, 29 May 2006 11:07:02 +0200 Subject: [cl-muproc-devel] [Patch] Reorganisation of impl-dependent functions: proposal In-Reply-To: <6E2AC665-29E5-48F8-80D4-2EC7C317A2B6@constantly.at> References: <6E2AC665-29E5-48F8-80D4-2EC7C317A2B6@constantly.at> Message-ID: <447AB9B6.3060500@mu.dk> Rudi Schlatte wrote: > Hello all, > > Thanks to the good work of Klaus, cl-muproc already has a good > separation of core functions and implementation-dependent code. There > is no explicit dependence on lispworks anywhere except > muproc-compat.lisp[1], so porting to other implementations should be > easy. In order to keep things tidy, I propose to gather each > implementation's code into its own file. The attached patch implements > this for lispworks. > > The patch also removes the dependency upon acl-compat. The rationale is > two-fold: > - some implementation-dependent code is necessary anyway, because > acl-compat does not implement lispworks-style mailboxes (nor > condition-variables, upon which mailboxes can be built). > - acl-compat pulls in cl-ppcre and puri, two libraries that are > completely unrelated to multiprocessing. > > With this patch, starting a new port would consist of: > - copying muproc-compat.lisp to muproc-.lisp > - adding the file to cl-muproc.asd > - implementing the stub functions in muproc-.lisp > > I feel this is a better solution than adding to an ever-expanding > muproc-compat.lisp. > > Cheers, > > Rudi > > > [1] The implicit dependence is without-scheduling, which presupposes the > scheduler is under control of the Lisp runtime. The last time I looked > at that part of the code in depth (on the train ride back from Hamburg), > I felt confident that the code without-scheduling could be rewritten > without it. Rudi -- Thanks for the patch! Sorry for being so slow in responding -- I have been effectively offline for a few days! I have taken a brief look at your patch and overall I think your proposal looks very sensible. I think I agree with getting rid of the dependency on acl-compat, since it is so small anyway. Your patch does cause a number of warnings in LW that I'd prefer to get rid of, so I'll take a better look at the code, probably later today (read: tonight). More later. best regards, -Klaus. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3368 bytes Desc: S/MIME Cryptographic Signature URL: From rudi at constantly.at Mon May 29 10:41:01 2006 From: rudi at constantly.at (Rudi Schlatte) Date: Mon, 29 May 2006 12:41:01 +0200 Subject: [cl-muproc-devel] [Patch] Reorganisation of impl-dependent functions: proposal In-Reply-To: <447AB9B6.3060500@mu.dk> References: <6E2AC665-29E5-48F8-80D4-2EC7C317A2B6@constantly.at> <447AB9B6.3060500@mu.dk> Message-ID: <77F8E38D-EE86-400E-91BA-912EF17F5BF3@constantly.at> On 29. Mai 2006, at 11:07, Klaus Harbo wrote: > I have taken a brief look at your patch and overall I think your > proposal looks very sensible. I think I agree with getting rid of > the dependency on acl-compat, since it is so small anyway. Your > patch does cause a number of warnings in LW that I'd prefer to get > rid of, so I'll take a better look at the code, probably later > today (read: tonight). More later. FWIW, I now think it's better to truncate muproc-compat so that it does not define the "stub" compat functions/macros. At least some warnings might be due to that. Another thing that doesn't warrant its own mail yet: I got most of the openmcl port done. What's missing is a stable version of muproc- spawn. It might be necessary to introduce another function in cl- muproc.comat, something like create-and-init-thread (thread-fn init- fn) that does the things muproc-spawn does inside the %without- scheduling% form. Lisp platforms that use native threads can't support without-scheduling, but at least in openmcl it is possible to create a thread structure without starting it, so cl- muproc.compat:create-and-init-thread will use without-scheduling on lispworks and create-thread->(funcall init-fn)->start-thread on openmcl. I'll send a patch once the basic muproc tests are running. Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From klaus at mu.dk Mon May 29 20:52:35 2006 From: klaus at mu.dk (Klaus Harbo) Date: Mon, 29 May 2006 22:52:35 +0200 Subject: [cl-muproc-devel] [Patch] Reorganisation of impl-dependent functions: proposal In-Reply-To: <4F3DA561-85AE-497E-8FD9-333EDCC8939B@constantly.at> References: <6E2AC665-29E5-48F8-80D4-2EC7C317A2B6@constantly.at> <447AB9B6.3060500@mu.dk> <77F8E38D-EE86-400E-91BA-912EF17F5BF3@constantly.at> <447ADF3A.4060707@mu.dk> <4F3DA561-85AE-497E-8FD9-333EDCC8939B@constantly.at> Message-ID: <447B5F13.2080905@mu.dk> Rudi Schlatte wrote: > > Sure, perhaps that way is better than what I am planning now - there > might well be a Lisp where there's no possibility of disallowing a > fresh thread from running. In that case, it might be necessary to let > the new muproc initialize the global state itself. In any case, > having your code will be helpful. > Hi Rudi -- > Btw, some tests in gensrv1-test.lisp fail for me on Mac lispworks > personal 4.4. I haven't investigated the failures at all but wanted > to ask: does gensrv1-test pass for you? Yes, it does: CL-USER> (push #p"~/lab/devel-muproc/" asdf:*central-registry*) (#P"/mu/home/klaus/lab/devel-muproc/" #P"/mu/home/klaus/lisp/sys/asdf-registry/" #P"/mu/lisp/sys/asdf-registry/") CL-USER> (push #p"~/lab/devel-muproc/tests/" asdf:*central-registry*) (#P"/mu/home/klaus/lab/devel-muproc/tests/" #P"/mu/home/klaus/lab/devel-muproc/" #P"/mu/home/klaus/lisp/sys/asdf-registry/" #P"/mu/lisp/sys/asdf-registry/") CL-USER> (asl :cl-muproc) ; loading system definition from ;;; ...elided... NIL CL-USER> (asl :cl-muproc-test) ; loading system definition from ;;; ...elided... NIL CL-USER> (muproc-test::do-tests) Doing 27 pending tests of 27 tests total. MUPROC-TEST::SIMPLE-1 MUPROC-TEST::SIMPLE-2 MUPROC-TEST::SIMPLE-3 MUPROC-TEST::SIMPLE-4 MUPROC-TEST::SIMPLE-5 MUPROC-TEST::MUPROC-EXIT-LINK-1 MUPROC-TEST::NORMAL-EXIT-LINK-2 MUPROC-TEST::LINKED-EXITS-3 MUPROC-TEST::RIPPLING-LINKED-EXITS-4 MUPROC-TEST::RIPPLING-LINKED-EXITS-4A MUPROC-TEST::REGISTER-1 MUPROC-TEST::COMPUTATION-1 MUPROC-TEST::UNIQUE-MUPROC-NAMES-1 MUPROC-TEST::UNIQUE-MUPROC-NAMES-2 MUPROC-TEST::SEND-TO-TERMINATED-1 MUPROC-TEST::SEND-TO-TERMINATED-2 MUPROC-TEST::MUPROC-SEND-1 MUPROC-TEST::MUPROC-MONITOR-1 MUPROC-TEST::INTERRUPT-1 MUPROC-TEST::TWO-INSTANCES-1 MUPROC-TEST::TWO-INSTANCES-2 MUPROC-TEST::TWO-INSTANCES-3 MUPROC-TEST::DEFAULT-INSTANCE-1 MUPROC-TEST::DEFAULT-INSTANCE-2 MUPROC-TEST::CAST-1 MUPROC-TEST::PORT-NAME-1 MUPROC-TEST::HANDLE-TERM-1 No tests failed. T Some of the tests above are in gensrv1-test (this is the code you submitted, passing the test, btw). I dug a bit in the archives and found the code appended at the end. It's been a few months since I worked with this code, but the gist/idea of it is that instead of the SPAWNING Lisp process ensuring that all muproc invariants are established before the SPAWNED Lisp process gets to run, the invariants are established in the SPAWNED process instead. That way it we don't need the critical section (without-scheduling etc.). I believe this could work on both native and green thread based implementations. And, just to make it absolutely clear: I did not finish work on this code, it may very well contain flawed logic, missing code, or whatever! Still, when I did work with it, it did seem like a promising way to proceed. HTH, -Klaus. PS. Yes, the macrolet below is not strictly necessary, I was just trying to keep the amount of clutter down! ;;; sketch of refactored muproc-spawn -- BEWARE: NOT TESTED ;;; (defun wrapper-function (parent-process inport errorstream initial-bindings init-fn arglist) "The LISP process function, that is `wrapper-function' executes in the newly created LISP process. Sets up for muproc process, calls the primary muproc function and termination hooks, and detects and reports errors occurring in the `muproc' process. NOTE: Should only be called from `muproc-spawn'." (macrolet ((with-muproc-bindings (&body body) `(progv (append '(*muproc-inport* *muproc-errorstream* *named-ports* *pending-input* *muproc-packet* *muproc-mumsg* *timers* muproc.compat::*without-scheduling*) (mapcar #'car initial-bindings)) (append (list inport errorstream (make-hash-table :test #'eq) ;; named-ports (make-pending-input-array) ;; pending-input :unbound-value ;; *muproc-packet* :unbound-value ;; *muproc-mumsg* nil ;; timers nil ;; w/o-sched ) (mapcar #'cdr initial-bindings)) , at body))) (with-muproc-bindings (let ((signalling-arg)) (%with-debugging-stack% (let ((me (muproc-current-process))) (setf (muproc-port me) inport) (muproc-set-trap-exits trap-exits) (register-muproc-name name me) (when link (muproc-link parent-process me))) (handler-case ;; for handling any errors occurring in the run-time system (unwind-protect (handler-case ;; handle conditions originating in muproc user code (progn (apply init-fn arglist) (muproc-exit :normal-exit)) (muproc-linked-exit-condition (link-term-cond) ;; INV: The muproc is linked to a muproc which is terminating. (dbgformat 1 "Linked exit of ~s due to ~s." (muproc-name) link-term-cond) (setf signalling-arg (list :linked-to-exit (muproc-name (condition-muproc link-term-cond)) :for-reason (condition-reason link-term-cond)))) (muproc-externally-terminated-condition (term-cond) ;; INV: (muproc-kill ...) was called (dbgformat 0 "~a was terminated due to ~s." (muproc-name) term-cond) (setf signalling-arg (condition-reason term-cond))) (muproc-exit-condition (exit-cond) ;; handling... ;; INV: (muproc-exit ...) was called (dbgformat 1 "Got normal exit condition ~a." exit-cond) (setf signalling-arg (condition-reason exit-cond))) (error (err) (dbgformat 0 "Error occurred in muproc ~a: ~a." (muproc-name) err) (setf signalling-arg (cons :error-in-process err)))) (unwind-muproc signalling-arg)) (error (err) (muproc-log-errorstream "Internal error in ~a: ~a.~%" (muproc-name) err)))))))) (defun muproc-spawn (name init-fn arglist &key errorstream inport initial-bindings link trap-exits ;; TODO - fixme -- figure out to deal with muproc priorities in a portable manner #+lispworks (priority (%process-priority% (muproc-current-process))) #-lispworks (error "muproc priorities needs figuring out") ) "`muproc-spawn' is used to start new muproc processes. `name' must be a symbol, `init-fn' must be the process function, and `arglist' must be a list matching the lambda list of `init-fn'. `:errorstream' must be specified and must be a stream. `:initial-bindings' can be used to specify initial bindings for the created process, in which case it must be a list of conses, with the `car' being the name of the special variable to be bound, and the `cdr' being a form whose value when evaluated will be the initial binding of the symbol in the `car'. `link' indicates whether the submitting process is to be linked to the submitted process. `trap-exists' indicates whether the newly created muproc is to trap exits messages from linked muprocs, or receive a terminating condition signal on linked process exits." ;; ERRORSTREAM (when (not errorstream) (unless (boundp '*muproc-errorstream*) (error "Errorstream not specified and muproc:*muproc-errorstream* not bound.")) (setf errorstream *muproc-errorstream*)) (unless (typep errorstream 'stream) (error "Errorstream not a stream: ~a." errorstream)) ;; NAME (unless (symbolp name) (error "Muproc name not a symbol: ~s." name)) (let ((process-name (format nil "muproc-~d[~a~a]" (next-muproc-id) (if (keywordp name) ":" "") name))) (setf inport (or inport (make-instance 'muproc-port :name (format nil "IN<~a>" name)))) (unless (typep inport 'muproc-port) (error "Bad INPORT: ~a not a port." inport)) #+lispworks (unless (typep priority 'fixnum) (error "Process priority not a fixnum: ~a." priority)) (%with-exclusive-access% ;;%without-scheduling% (%process-run-function% process-name #+lispworks (list :priority priority) ;; LW process options #'wrapper-function (muproc-current-process) inport errorstream initial-bindings init-fn arglist)))) From klaus at mu.dk Mon May 29 21:01:41 2006 From: klaus at mu.dk (Klaus Harbo) Date: Mon, 29 May 2006 23:01:41 +0200 Subject: [cl-muproc-devel] [Patch] Reorganisation of impl-dependent functions: proposal In-Reply-To: <77F8E38D-EE86-400E-91BA-912EF17F5BF3@constantly.at> References: <6E2AC665-29E5-48F8-80D4-2EC7C317A2B6@constantly.at> <447AB9B6.3060500@mu.dk> <77F8E38D-EE86-400E-91BA-912EF17F5BF3@constantly.at> Message-ID: <447B6135.7080303@mu.dk> Rudi Schlatte wrote: > > On 29. Mai 2006, at 11:07, Klaus Harbo wrote: > >> I have taken a brief look at your patch and overall I think your >> proposal looks very sensible. I think I agree with getting rid of >> the dependency on acl-compat, since it is so small anyway. Your >> patch does cause a number of warnings in LW that I'd prefer to get >> rid of, so I'll take a better look at the code, probably later today >> (read: tonight). More later. > > FWIW, I now think it's better to truncate muproc-compat so that it > does not define the "stub" compat functions/macros. At least some > warnings might be due to that. Yes, they are. It's a dilemma, though, to my mind. I definitely want to get rid of the warnings, and removing the stub functions would do that. But on the other hand it is attractive to have a clear statement of the compat-functions required to make a full implementation. If we lose the stub functions, we'll lose that. Could changing :components ((:file "muproc-packages") (:file "muproc-compat" :depends-on ("muproc-packages")) #+lispworks (:file "muproc-lispworks" :depends-on ("muproc-compat")) (:file "muproc" :depends-on ("muproc-compat" #+lispworks "muproc-lispworks")) (:file "generic-server" :depends-on ("muproc")) (:file "supervisor" :depends-on ("muproc")) )) in cl-muproc.asd to something along the lines of :components ((:file "muproc-packages") #-(or lispworks other-impl) (:file "muproc-compat" :depends-on ("muproc-packages")) #+lispworks (:file "muproc-lispworks" :depends-on ("muproc-packages")) #+other-impl (:file "muproc-other-impl" :depends-on ("muproc-packages")) (:file "muproc" :depends-on (#-(or lispworks other-impl) "muproc-compat" #+lispworks "muproc-lispworks" #+other-impl "muproc-other-impl")) (:file "generic-server" :depends-on ("muproc")) (:file "supervisor" :depends-on ("muproc")) )) perhaps balance these requirements? Perhaps someone can point to a model from other projects that we can use/borrow/steal? > > Another thing that doesn't warrant its own mail yet: I got most of the > openmcl port done. What's missing is a stable version of > muproc-spawn. It might be necessary to introduce another function in > cl-muproc.comat, something like create-and-init-thread (thread-fn > init-fn) that does the things muproc-spawn does inside the > %without-scheduling% form. Lisp platforms that use native threads > can't support without-scheduling, but at least in openmcl it is > possible to create a thread structure without starting it, so > cl-muproc.compat:create-and-init-thread will use without-scheduling on > lispworks and create-thread->(funcall init-fn)->start-thread on > openmcl. I'll send a patch once the basic muproc tests are running. > > Cheers, > > Rudi > See my previous posting. -Klaus. From rudi at constantly.at Tue May 30 13:30:17 2006 From: rudi at constantly.at (Rudi Schlatte) Date: Tue, 30 May 2006 15:30:17 +0200 Subject: [cl-muproc-devel] [Patch] Reorganisation of impl-dependent functions: proposal In-Reply-To: <447B6135.7080303@mu.dk> References: <6E2AC665-29E5-48F8-80D4-2EC7C317A2B6@constantly.at> <447AB9B6.3060500@mu.dk> <77F8E38D-EE86-400E-91BA-912EF17F5BF3@constantly.at> <447B6135.7080303@mu.dk> Message-ID: On 29. Mai 2006, at 23:01, Klaus Harbo wrote: > Rudi Schlatte wrote: >> >> FWIW, I now think it's better to truncate muproc-compat so that it >> does not define the "stub" compat functions/macros. At least some >> warnings might be due to that. > > Yes, they are. It's a dilemma, though, to my mind. I definitely > want to get rid of the warnings, and removing the stub functions > would do that. But on the other hand it is attractive to have a > clear statement of the compat-functions required to make a full > implementation. If we lose the stub functions, we'll lose that. Hmm, muproc-compat.lisp (in your proposal below) would be essentially documentation, and would only be loaded on otherwise unsupported Lisp implementations. In that light, would it make sense to create muproc- compat.txt (or porting.txt) and document the muproc-compat interface there? Alternatively, the documentation could also be written as comments in the :exports section of the defpackage form for the cl- muproc.compat package. > > Could changing > > :components > ((:file "muproc-packages") > (:file "muproc-compat" :depends-on ("muproc-packages")) > #+lispworks (:file "muproc-lispworks" :depends-on ("muproc-compat")) > (:file "muproc" :depends-on ("muproc-compat" > #+lispworks "muproc-lispworks")) > (:file "generic-server" :depends-on ("muproc")) > (:file "supervisor" :depends-on ("muproc")) > )) > > in cl-muproc.asd to something along the lines of > > :components > ((:file "muproc-packages") > #-(or lispworks other-impl) (:file "muproc-compat" :depends-on > ("muproc-packages")) > #+lispworks (:file "muproc-lispworks" :depends-on ("muproc- > packages")) > #+other-impl (:file "muproc-other-impl" :depends-on ("muproc- > packages")) > (:file "muproc" :depends-on (#-(or lispworks other-impl) "muproc- > compat" > #+lispworks "muproc-lispworks" > #+other-impl "muproc-other-impl")) > (:file "generic-server" :depends-on ("muproc")) > (:file "supervisor" :depends-on ("muproc")) > )) > > perhaps balance these requirements? Perhaps someone can point to a > model from other projects that we can use/borrow/steal? As said above, since muproc-compat.lisp is only for documentation purposes in the second form, I personally would write proper documentation instead. :) Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: