I think I lack background on how standards are made and adopted, so would appreciate input from anyone who remembers or has read about CL's formation. Is there a "The making of ANSI CL" document?
This is not a top-post... On Wed, Jul 26, 2006 at 03:10:44PM +0100, Marco Monteiro wrote: > Matthew Astley wrote: > > [...] any reason not to say that SSC shall be a nickname? > > I don't understand what is the problem. Note that if some code needs to > determine which SSC implementation it is using, then SSC has failed. I'm not saying there's a problem, just that it may be more useful another way. You're right, the code shouldn't *need* to determine the SSC implementation. Sometimes it might want to, anyway. > At most, it might be interesting to know which CL implementation you > are using, and that is easy. There may not be a 1:1 mapping of CL:SSC implementation, some CLs may also have experimental or crippleware versions. Perl had two different threading models, I don't know the details. The suggestion to make ssc a nickname costs but ten words in the spec and maybe a couple of test cases. The possible benefits (apart from what Marco.A said) are small but significant. For more definite version info, specific calls might be better? CL defines for itself (lisp-implementation-type) => "SBCL" (lisp-implementation-version) => "0.9.9" and the package is "COMMON-LISP" aka. "CL". This gives me another thought. You say if the code needs to know, then SSC has failed; but this may only be a partial failure if most of it works. Does this mean there will be only an :ssc pushed to *features* ? I'm thinking that if there is possibility of some parts of SSC being incorrectly or incompletely supported, it could make it easier for authors to work around problems if there are relevant *features*. It's not to expect failure, just "belt and braces". CL defines a bunch of stuff. It sounds like these were helpful to people writing code while the standard was developed? (I wasn't there) http://lisp.org/HyperSpec/Body/var_stfeaturesst.html > > | [...] This function returns an unspecified value. [...] > > | A spurious wakeup is the unblocking of a thread waiting on a > > state-change > > | variable that happens without other thread signalling the state-change > > variable. > > | To allow greater flexibility, implementations are allowed to have this > > behaviour. > > | Because of this, the state-change variable's predicate must always be > > checked. > > > > This form of the spec requires all code to do the check, even when it > > isn't needed. This seems wasteful. > > > > If signal-state-change were to return true when the wakeup is not > > spurious, this will require some implementations to do the check at > > the tail of signal-state-change; but those that don't generate > > spurious wakeups will cut some code out. > > > > In both cases, the spec and implementation have taken on a little > > extra responsibility, but the users win each time they use it. > > It can be very hard and much more 'expensive' to implement condition > variables if spurious wakeups are not permitted. Sure, I figured there would be a reason why spurious wakeups are passed. I'm not suggesting to ban spurious wakeups, but for the call to return a value indicating whether the wakeup is spurious - if it can be tested, why leave the testing to the user when you have a conveniently placed undefined return value? > > Moving on to review.tex, [stuff about threads dying / being reset] > > If [thread creation overhead is] small enough, maybe the loss > > isn't worth the burden of the wrapper library upon other > > implementations... but if the cost is even suspected to be large > > then vendors with reset functionality might be reluctant to have > > it hidden (making your "sales" job that much harder) and their > > users may stick with the implementation-specific calls (making > > chunks of code less portable). I think I didn't make this clear. My theory is, if we suspect there may be difficulty getting the majority of vendors on board with SSC then it makes sense to think of the reasons it might be rejected and address those. One of the reasons, in a generalised way, is "our implementation supports <foo> and SSC doesn't allow this feature, so by adopting SSC we must reduce our feature-set; therefore we will promote our proprietary API instead". The reverse is "our implementation cannot support <foo> ( because of the way we chose to implement <bar> | for performance reasons ) and SSC requires it". Until you have implementors contributing to the SSC spec you may only guess what they might want, then try to fit it in. > > The alternative is to offer wrapper code which supplies the missing > > functionality - if this can be done for all implementations. > > This must be decided by the implementors. If SSC offers a zero-cost and any-licence-compatible implementation which can bolt on the extra features in a wrapper, then surely this must improve the chances of wide SSC adoption? Matthew #8-) _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
