From masm at acm.org Tue Aug 1 12:24:48 2006 From: masm at acm.org (Marco Monteiro) Date: Tue, 01 Aug 2006 13:24:48 +0100 Subject: [ssc-devel] Changes. Message-ID: <44CF4810.6020105@acm.org> There are some changes in the specification. There is now a rationale (the start of, actually). This will need much work. Its current text is mainly some observation that were made in the CL Gardeners mailing list. I'll be working in this section of the document in the next weeks. Help would be greatly appreciated, of course. Names for synchronization primitives have been removed. In their place there is a new :reason key argument to all functions that can block the current thread. I gave the rationale for this in a previous email to this mailing list, and I'll put something in the specification when I find time to do it. What do you think? Is this better? (Note that names for synchronization primitives can be addressed with the new extension mechanism.) The major change is the new extension mechanism. Read the latest revision of the specification to know all about this. There is also an example of its use in the project page (http://common-lisp.net/project/ssc/). That is how I expect the mechanism to be used. Remember that all the changes to the specification are reversible. If you don't like something, please speak up. Comments, please. Cheers, Marco From masm at acm.org Wed Aug 2 09:26:20 2006 From: masm at acm.org (Marco Monteiro) Date: Wed, 02 Aug 2006 10:26:20 +0100 Subject: [ssc-devel] PASS-BARRIER/TIMEOUT is not useful. Message-ID: <44D06FBC.6080106@acm.org> I'm currently using pass-barrier/timeout heavily in the test suite. Apart from its use there, I can't see any use for it. Unless someone can think of an use for it, I think that it should be thrown out. Any thoughts? Cheers, Marco From clgard$mca at t8o.org Wed Aug 2 21:44:48 2006 From: clgard$mca at t8o.org (Matthew Astley) Date: Wed, 2 Aug 2006 22:44:48 +0100 Subject: [ssc-devel] PASS-BARRIER/TIMEOUT is not useful. In-Reply-To: <44D06FBC.6080106@acm.org> References: <44D06FBC.6080106@acm.org> Message-ID: <20060802214448.GO3629@t8o.org> On Wed, Aug 02, 2006 at 10:26:20AM +0100, Marco Monteiro wrote: > I'm currently using pass-barrier/timeout heavily in the test suite. > Apart from its use there, I can't see any use for it. Anything that makes testing easier is probably worth keeping, even if it has no other use. Could you post a URL for the test code in which it is useful? Currently I have no application requiring threads[1] so I can only attempt to contrive another useful case. The first project on my "to do one day" list that might require threads probably only needs them because it may be network-bound. > Unless someone can think of an use for it, I think that it should be > thrown out. > > Any thoughts? What is the cost of leaving it in? Or perhaps in an easier to answer form: across all likely implementations, what might be the average and maximum costs of leaving it in? Alternatively, if you preferred to trim down to a core SSC spec and then offer an ssc-extra package in some cases, will this impact the usefulness of the spec? Is a programmer can't rely on functionality being present he's back to either rolling his own, pulling in a library or coding it up for some subset of vendors. You may see these are generic comments, which might apply to anything else just as well... Matthew #8-) -- [1] apart from serving concurrent but independent HTTP requests: TBNL does all the work for me, using in turn KMRCL. From masm at acm.org Sat Aug 5 08:37:03 2006 From: masm at acm.org (Marco Monteiro) Date: Sat, 05 Aug 2006 09:37:03 +0100 Subject: [ssc-devel] PASS-BARRIER/TIMEOUT is not useful. In-Reply-To: <20060802214448.GO3629@t8o.org> References: <44D06FBC.6080106@acm.org> <20060802214448.GO3629@t8o.org> Message-ID: <44D458AF.2030409@acm.org> Matthew Astley wrote: > On Wed, Aug 02, 2006 at 10:26:20AM +0100, Marco Monteiro wrote: > >> I'm currently using pass-barrier/timeout heavily in the test suite. >> Apart from its use there, I can't see any use for it. > > Anything that makes testing easier is probably worth keeping, even if > it has no other use. The function can be implemented in the test suite. > Could you post a URL for the test code in which it is useful? > Currently I have no application requiring threads[1] so I can only > attempt to contrive another useful case. The test suite is in a Darcs directory: http://common-lisp.net/project/ssc/darcs/test There is a link in the project page. Right now it is not very useful, as there is no implementation to test. > What is the cost of leaving it in? Or perhaps in an easier to answer > form: across all likely implementations, what might be the average and > maximum costs of leaving it in? If a function will never be used, then it should not be in the specification. There is an equilibrium that must be maintained. Semaphores, barriers, and read/write locks can all be implemented with mutual exclusion locks and condition variables. They are included because they can benefit, in terms of performance, from being in the specification. If a function on one of these three objects (or any other) will never be used, it should not be in the specification. Cheers, Marco From gimmal at gmail.com Sun Aug 6 04:51:54 2006 From: gimmal at gmail.com (Sean Champ) Date: Sat, 5 Aug 2006 21:51:54 -0700 Subject: [ssc-devel] (1) question : ssc implementation; (2) code-share: some locking procedures onto SBCL Message-ID: <200608052151.55392.gimmal@gmail.com> Hello, I had noticed, today, that SSC was mentioned in the 'recent projects' listing at common-lisp.net. I had wanted to find out what there was to the project, and so, I visited the project's home page. Upon reading the SSC specification -- that is a throughly impressive work, by the way, I think it must be helpful in explaining the materials of the project, to a developer who would be unfamiliar with the materials, and for clarifying the materials, as to a developer who may be already familiar with the materials. I consider that SSC should serve as a foundation for the support of what is addressed in the SSC specification, addressing it on a cross-platform basis, within a single codebase, such that may be applied across implementations of more systems. I consider that McCLIM may be patched to use SSC, but I would like to inquire: How do you prefer that the implementation of the SSC specification will be approached? Upon reading the SSC specification, it appears to me that the material of the SSC specification may be addressed, readily, directly onto the threading implementation in SBCL -- at mutexes and semaphorse, namely. In the more, I presume it may all be approached in extension of the SBCL threading implementation -- this, then, in the implementation onto SBCL. If the SSC project would be open for contributions in the implementation of the SSC specification, as within an SB-Threads environment, I would like to volunteer for the effort. I've attached to this email what represents the body of experience that I have had in regards to threading, in SBCL. As in summary about the attachment: 1) Given that I have not been in active development of any public systems, I consider that it may be of help, that I would present an item of code that I have written, in case you may accept my offer for to be a contributor onto SSC, onto SBCL. I would say that with the clause, in regards to commentary and documentation in the code: I had written that item of code at a time when there was no clear hope that it would be published. I do not much like the look of the text of it, now; it may appear somehow cruftified, of the commentary in the code. It is an item of available code -- and I have not touched it, in some while. (Given the character of some comments that I have observed about writing made of my person, I am certain that the text in the attached file would stand as if to insprire such commentary, again. At this point, I am not much concerned of it, though I observe that it is so.) 2) I'd consider it to be licensed as some public domain code, simply. 3) The code in the file constitutes an implementation of the following, onto SBCL: - Modal locking - i.e. read/write locking - Lock acquisition with timeout - A macro WITH-TIMER, made as an extension onto SBCL's SB-EXT:WITH-TIMEOUT macro. The extension suports that an actual TIMER object would be supplied to the macro. That, in turn, will support that a user-specified TIMEOUT-FUNCTION will be called on the timer, in case of a timeout. - The definition of a distinct condition type, LOCK-BLOCKED-ERROR, such that will be produced as a consequence of some defaulted values, then produced in a timed-out call to expansion of the WITH-TIMER macro - A trivial protocol for acquisition and release of locks; that protocol was implemented as to be driven on generic functions. - Some preliminary attempts at supporting the code, onto ACL hosts; I cannot expect that those attempts will be certain to work, and they are incomplete. I may recommend that that functions of the generic-function protocol would be regarded only as an example. When I had implemented it with a generic-function-driven protocol, I had wanted the range for flexibility, afforded with generic functions; I consider, now, that that was a premise taken in some naivete. Latterly, presently -- though the generic function qualities of it have supported that MODAL-LOCK objects would be used beside more directly MUTEX typed objects -- I woud not recommend that it would be applied as so. The set of operations that are used for standard method dispatching on generic functions, those operations should not need to be required, in the execution of a locking facility. Both of modal locks and absolute locks may be initialized via a one function. The differentiation of modality may be predicated on the value of a :MODE argument, typed (MEMBER :READ :WRITE NIL). There may be defined a single function operating for the release of a lock. That function may be defined as to operate by way of a simple two-typed dispatch -- handling a MODAL-LOCK (?) differently than a plainer LOCK, within the body of the function. If you would be interested in the contribution, I would be glad to clean up the attached code, and to address it onto SSC, as for an implementation of the SSC specification onto SBCL hosts. I look forward to being able to use SSC within implementations. I am impressed with the breadth and the quality of the SSC specification, and with your careful approach to the project, such that is apparent on consideration. I would be glad to have an opportunity to contribute. I recognize, it is your own perogative, as for how you will approach the implementation of SSC. Cordially, -- Sean Champ gimmal at gmail.com user 'schamp' at common-lisp.net -------------- next part -------------- A non-text attachment was scrubbed... Name: threading.lisp Type: text/x-lisp Size: 34417 bytes Desc: not available URL: