comment on the adoption (or lack thereof) of these common frameworks.

[Joe Pendergast]

This just a philosophical comment that I have on the choices one frquently encounters in supporting portability. My comment speciifically is in reference to the Semaphore class but it is precisely a comment in the class documentation that caused me to write.

 

In particular in supporting and driving towards portability the drive towards absolute functional compatibility/portability drives the implementations towards least common denominator implementations.

An example of this is the lack of timeout functionality in:

 

void Semaphore::wait

(

void

)

Wait is used to keep a thread held until the semaphore counter is greater than 0. If the current thread is held, then another thread must increment the semaphore. Once the thread is accepted, the semaphore is automatically decremented, and the thread continues execution. The pthread semaphore object does not support a timed "wait", and hence to maintain consistancy, neither the posix nor win32 source trees support "timed" semaphore objects.

My objection to this sort of least common denominator guiding philosophy is that many potential users will NOT adopt the frame work because of the loss of functionality - thus in some sense a least common denominator philosophy is contradictory to the goal popular adoption of a common framework. (We technicians sometimes tend to ignore such realities in our efforts.)

 

Wouldn't it be better provide the functionality in the interface and

 

1) throw an unsupported operation exception

or

2)quietly discard the timeout functionality in those implementations that do not support it (This I will grant to be problematic as Servers that use the timeout functionality as a method of breaking their "wait for work" primitive (implemented with a timed semaphore P operation) in order to poll a shutdown request variable or the like would not work. But they would not be portable in any case.........

 

In any case this is meant more to discuss the "least common denominator philosophy" rather than this specific example.

 

I just wanted to raise this philosophical point and find out where the developers stood on this issue. (As obviously in the limiitng case of an OS or implementing API set not supporting semaphores at all probably would have been grounds for ignoring such an underlying implementation environment I wondered where the line was drawn.......

 

Best wishes in your efforts though.