David, this is what the suggested semaphore.cpp/semaphore.hpp. Is that what you are looking for?
Webrev: http://cr.openjdk.java.net/~rbackman/webrev/ Thanks /R On Apr 15, 2013, at 8:59 AM, David Holmes wrote: > On 15/04/2013 4:55 PM, Rickard Bäckman wrote: >> David, >> >> any new thoughts? > > Not a new one but I think factoring into Semaphore.hpp/cpp and using a few > ifdefs is better than three versions of the Semaphore class. The signal > thread could use it also. > > David > >> Thanks >> /R >> >> On Apr 12, 2013, at 8:06 AM, Rickard Bäckman wrote: >> >>> >>> On Apr 12, 2013, at 7:34 AM, David Holmes wrote: >>> >>>> On 12/04/2013 3:01 PM, Rickard Bäckman wrote: >>>>> >>>>> On Apr 12, 2013, at 1:04 AM, David Holmes wrote: >>>>> >>>>>> On 11/04/2013 11:02 PM, Rickard Bäckman wrote: >>>>>>> On Apr 11, 2013, at 2:39 PM, David Holmes wrote: >>>>>>>> So what did you mean about pthread_semaphore (what is that anyway?) ?? >>>>>>> >>>>>>> Never mind, pthread condition variables. >>>>>> >>>>>> Ah I see. >>>>>> >>>>>>>> >>>>>>>> I really, really, really don't like seeing three versions of this >>>>>>>> class :( Can't BSD and Linux at least share a POSIX version? (And I >>>>>>>> wonder if we can actually mix-n-match UI threads on Solaris with POSIX >>>>>>>> semaphores on Solaris?) >>>>>>> >>>>>>> I don't like it either, our OS code isn't really helpful when it comes >>>>>>> do reusing things :) Not sure how I would layout things to make them >>>>>>> only available on BSD (Not Mac) and Linux. I guess os_posix.hpp with >>>>>>> lots of #ifdefs, but I'm not sure I"m feeling that happy about that. >>>>>> >>>>>> Why would the os_posix version need a lot of ifdefs? >>>>> >>>>> Well, I guess we would need: >>>>> >>>>> (in ifdef pseudo language) >>>>> >>>>> #ifdef (LINUX || (BSD && !APPLE)) >>>>> … >>>>> #endif >>>> >>>> But if it isn't "posix" then we won't be building os_posix - right? >>> >>> Linux, Solaris, Bsd & Mac builds and include os_posix. They are all >>> "implementing posix" we are just not using the same semaphore >>> implementation on all of them. >>> >>>> >>>>> The second interesting problem this will get us into is that sem_t is not >>>>> declared in this context. Where do we put the #include <semaphore.h>? >>>>> Impossible in os_posix.hpp since it is included in the middle of a class >>>>> definition. I could put it in os.hpp in the #ifdef path that does the >>>>> jvm_platform.h includes, not sure if that is very pretty either. >>>> >>>> Semaphores are already used by the signal handler thread - semaphore.h is >>>> included in os_linux.cpp etc, so why would os_posix be any different ? >>>> >>>> But couldn't we just have a Semaphore.h/cpp with any needed ifdefs? >>>> >>>>>> Do we really have four versions: >>>>>> - linux (posix) >>>>>> - BSD (posix) >>>>>> - Solaris >>>>>> - Mac (different to BSD?) >>>>>> >>>>> >>>>> 3: >>>>> 1) linux & bsd uses the sem_ interface >>>>> 2) solaris uses the sema_ interface >>>>> 3) mac uses the semaphore_ interface >>>> >>>> Okay but if mac is BSD why can't we use bsd ie posix interface instead of >>>> the mach semaphore_ ? >>> >>> Because apple decided not to implement sem_timedwait. >>> On Solaris we use sema_ because sem_ requires us to link with -lrt which we >>> currently don't (and I'm not really feeling like adding it) >>> >>>> >>>> >>>> BTW I like the idea of using the semaphore, we're just haggling on the >>>> details. ;-) >>> >>> I'm fine with that :) >>> >>> /R >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> /R >>>>> >>>>>> ?? >>>>>> >>>>>> David >>>>>> ----- >>>>> >>> >>
