ssc-devel August 2006

ssc-devel@common-lisp.net

3 participants
3 discussions

[ssc-devel] (1) question : ssc implementation; (2) code-share: some locking procedures onto SBCL
by Sean Champ 06 Aug '06

06 Aug '06

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(a)gmail.com user 'schamp' at common-lisp.net

1 0

[ssc-devel] PASS-BARRIER/TIMEOUT is not useful.
by Marco Monteiro 05 Aug '06

05 Aug '06

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

2 2

[ssc-devel] Changes.
by Marco Monteiro 01 Aug '06

01 Aug '06

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

ssc-devel August 2006