[ssc-devel] (1) question : ssc implementation; (2) code-share: some locking procedures onto SBCL

[Sean Champ]

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: <https://mailman.common-lisp.net/pipermail/ssc-devel/attachments/20060805/41b47cc1/attachment.bin>