Hmmm, I don't see how the code I copied could ever have worked. The test
for a timeout completion is completely wrong, since the time passed into
the function is an absolute time, it would end up counting down until the
remaining time is zero. Thanks what I get for trusting that an example I
find on the internet is actually correct.

Rick

On Sat, Mar 9, 2019 at 2:58 PM Enrico Sorichetti via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

> Hello Rick,
> I looked  at  the unix/SysSemaphore.cpp file.
>
> I noticed a couple of things,
>
> Nanosleep wants an interval not a wakeup time,
> DESCRIPTION
>      The nanosleep() function causes the calling thread to sleep for the
> amount of time specified in rqtp
>
>
> So right now given the call to SysSemaphore::createTimeOut
> It would have waited - I tested about 45 minutes ago - around 20 hours
>
> RETURN VALUES
>      If nanosleep() returns because the requested time has elapsed, the
> value returned will be zero.
>
>      If nanosleep() returns due to the delivery of a signal, the value
> returned will be the -1, and the global variable errno will be set to
> indicate the
>      interruption.  If rmtp is non-NULL, the timespec structure it
> references is updated to contain the unslept amount (the request time minus
> the time
>      actually slept).
>
> So in case of a successful wait , most probably the struct timespec slept
> Will contain garbage
>
> I will keep investigating
>
> E
>
> Ps
> What is the unit of measure of 50  in
> self~assertFalse(sem~acquire(50)) ?
>
>
>
>
>
>
> On 9 Mar 2019, at 16:29, Rick McGuire <object.r...@gmail.com> wrote:
>
> This does not use the same semaphores that SysMutexSemaphore uses, it uses
> the same abstraction classes that the interpreter uses internally. If those
> don't work, then the testsuite would be falling over all over the place.
> The line that's hanging is the first line that uses the replacement
> pthread_mutex_lockedwait() function, so this function just needs a little
> debugging. I'm going to be a bit busy today, but when I get a chance, I'll
> see if I can reproduce the hang in scaffold mold on Ubuntu, but if you can
> provide any debugging information before that it would be helpful. The
> function is located in the unix/SysSemaphore.cpp file.
>
> Rick
>
> On Sat, Mar 9, 2019 at 9:33 AM Enrico Sorichetti via Oorexx-devel <
> oorexx-devel@lists.sourceforge.net> wrote:
>
>> OOPS …
>> I had forgotten to run svn update for the test-suite
>>
>> The ooRexx/base/class/MutexSemaphore.testGroup
>>
>> Hangs  on statement 72
>>
>> IMO the test group should not be run on Darwin,
>> The documentation is clear, unnamed semaphores are not supported
>>
>> E
>>
>>
>>
>> On 9 Mar 2019, at 13:04, Enrico Sorichetti <enricosoriche...@mac.com>
>> wrote:
>>
>> Thank You Rick,
>> It builds and runs the testsuite
>> E
>>
>>
>> On 9 Mar 2019, at 12:45, Rick McGuire <object.r...@gmail.com> wrote:
>>
>> I found some code that can be used as a replacement for
>> pthread_mutex_timedlock if it is not available. This builds cleanly for me
>> on Ubuntu in "fake out" mode. Please try building with the latest version
>> to verify it builds.
>>
>> Rick
>>
>>
>>
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to