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
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
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