[Seaside-dev] WAMutex

[Julian Fitzell]

As with Issue 499, Seaside-(Squeak-)Core can add a method to the
platform so there is no need to move WAMutex itself into Grease
(though perhaps a mutex *is* something that Grease could/should
provide). I think #semaphoreClass makes sense as a Grease method since
any number of projects might need to use sempahores.

I can't decide how I feel about the trend of adding platform methods
to get at more and more classes though... I don't mind the basic
principle but it seems like a slippery slope.

In general (so far) platform methods are used either to:
  1) perform specific functionality that is accomplished differently
on some platforms; or
  2) return base system classes that have the same/similar protocol
but different names on some platforms

Platform-specific versions of our own classes are implemented using a
superclass that defines the protocol and a #current class-side method
that returns a subclass implementation. It occurs to me that we could
actually make #new work for these classes (self isAbstract ifTrue:
[self current new] ifFalse: [super new]) but not sure if that's too
magical.

I suppose the best solution /is/ somewhat dependent on the extent of
the modifications to WAMutex and the number of other changes that you
need to make.

Julian



On Mon, Nov 23, 2009 at 2:03 PM, Dale Henrichs
<dale.henrichs at gemstone.com> wrote:
> I'd like to swap out the grease method for #semaphoreClass, with a grease method to answer with the #mutex class (which would involve moving WAMutex to Grease) .. the only other place that the semaphoreClass is used is in a test and since that's not involved in persistence it could be a real semaphore in GemStone too...
>
> Of course, we could leave the #semaphoreClass method just in case it needs to be used in the future ...
>
> Since WAMutexes(WAMutexi?) are persisted, I need transient protection for both the Semaphore and process references ... the process could have a direct Semaphore reference in the stack ....
>
> WAMutex is used in WAMutualExclusionFilter and WACache ...
>
> I _could_ subclass WACache, but then I'd want a way to inject the GemStone cache as the default since WACache would not be usable/recommended in GemStone...
>
> Again, for the short term, I can create a GemStone-specific package witht a direct override until we come up with a satisfactory resolution for this and the other issues I'm sure to bump into.
>
> If a solution is a no-brainer, then we should do it relatively soon, but if we're choosing between hacks, then it is worth waiting until I've uncovered more of the persistence issues...
>
> Dale
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>