On Dec 1 08:49, Brian Inglis wrote:
> On 2018-12-01 02:53, Corinna Vinschen wrote:
> > On Nov 30 21:27, Brian Inglis wrote:
> >> $ head /{etc,usr/lib}/os-release
> >> ==> /etc/os-release <==
> >> PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
> >> NAME="Debian GNU/Linux"
> >> VERSION_ID="9"
> >> VERSI
On 2018-12-01 02:53, Corinna Vinschen wrote:
> On Nov 30 21:27, Brian Inglis wrote:
>> On 2018-11-30 05:56, Corinna Vinschen wrote:
>>> On Nov 30 07:43, James E. King III wrote:
On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen wrote:
> On Nov 29 17:38, James E. King III wrote:
>> On Th
On Nov 30 21:27, Brian Inglis wrote:
> On 2018-11-30 05:56, Corinna Vinschen wrote:
> > On Nov 30 07:43, James E. King III wrote:
> >> On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen wrote:
> >>> On Nov 29 17:38, James E. King III wrote:
> On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen wrot
On 2018-11-30 05:56, Corinna Vinschen wrote:
> On Nov 30 07:43, James E. King III wrote:
>> On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen wrote:
>>> On Nov 29 17:38, James E. King III wrote:
On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen wrote:
> I created a patch and uploaded new dev
On Nov 30 07:43, James E. King III wrote:
> On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen
> wrote:
> >
> > On Nov 29 17:38, James E. King III wrote:
> > > On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen
> > > > I created a patch and uploaded new developer snapshots to
> > > > https://cygwin.co
On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen
wrote:
>
> On Nov 29 17:38, James E. King III wrote:
> > On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen
> > > I created a patch and uploaded new developer snapshots to
> > > https://cygwin.com/snapshots/ Please give them a try.
> >
> > This fixed
On Nov 29 17:38, James E. King III wrote:
> On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen
> > I created a patch and uploaded new developer snapshots to
> > https://cygwin.com/snapshots/ Please give them a try.
>
> This fixed the issue for me. What's the best way to detect cygwin
> with this s
ov 25 09:01, James E. King III wrote:
> > > > > I have isolated a problem in pthread_cond_timedwait when the condattr
> > > > > is used to set the clock type to CLOCK_MONOTONIC. In this case even
> > > > > though a target time point in the future
On Nov 26 17:46, Corinna Vinschen wrote:
> On Nov 26 10:47, James E. King III wrote:
> > On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen
> > wrote:
> > >
> > > On Nov 25 09:01, James E. King III wrote:
> > > > I have isolated a problem in pthread_con
On Nov 26 10:47, James E. King III wrote:
> On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen
> wrote:
> >
> > On Nov 25 09:01, James E. King III wrote:
> > > I have isolated a problem in pthread_cond_timedwait when the condattr
> > > is used to set the clo
On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen
wrote:
>
> On Nov 25 09:01, James E. King III wrote:
> > I have isolated a problem in pthread_cond_timedwait when the condattr
> > is used to set the clock type to CLOCK_MONOTONIC. In this case even
> > though a target tim
On Nov 25 09:01, James E. King III wrote:
> I have isolated a problem in pthread_cond_timedwait when the condattr
> is used to set the clock type to CLOCK_MONOTONIC. In this case even
> though a target time point in the future is specified, the call
> returns ETIMEDOUT but a subseq
I have isolated a problem in pthread_cond_timedwait when the condattr
is used to set the clock type to CLOCK_MONOTONIC. In this case even
though a target time point in the future is specified, the call
returns ETIMEDOUT but a subsequent call to
clock_gettime(CLOCK_MONOTONIC) shows the desired
On Feb 12 12:10, [EMAIL PROTECTED] wrote:
> Hi,
> I have tried to use the pthread_cond_timedwait, but it doesn't seem to
> work properly.
>
> It returns immediately with a return value of 116 (ETIMEDOUT) even if I
> set the timeout period to e.g. 10 seconds.
>
>
Hi,
I have tried to use the pthread_cond_timedwait, but it doesn't seem to
work properly.
It returns immediately with a return value of 116 (ETIMEDOUT) even if I
set the timeout period to e.g. 10 seconds.
I have locked the mutex and initialized the condition variable before
the invokati
Sorry, its already fixed in last version.
--
Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentati
In the code below, the timespec argument to pthread_cond_timedwait() is set
to an invalid value: t_nsec > 999,999,999 so, EINVAL error code should be
returned.
Regards,
Ivan Mari
#include
#include
#include
#include
#include
void* start_routine( void* arg );
pthread_cond_t m_c
> I would like to use this function down to 10 milliseconds accuracy if
> possible.
> However upon looking at winsup/cygwin/thread.cc,
> it uses the function "ftime" and the millisecond field is ignored.
This is already fixed. Try the snapshot.
Bit do not expect that you can use it with 10 ms del
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
> Of peter garrone
> I would like to use this function down to 10 milliseconds
> accuracy if possible.
> However upon looking at winsup/cygwin/thread.cc,
> it uses the function "ftime" and the millisecond field is ignored.
>
> All the exam
-Original Message-
From: "peter garrone" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Mon, 25 Aug 2003 15:42:52 +0800
Subject: pthread_cond_timedwait accurate to one second only
Hi.
I would like to use this function down to 10 milliseconds accuracy if possible.
Howe
Hi.
I would like to use this function down to 10 milliseconds accuracy if possible.
However upon looking at winsup/cygwin/thread.cc,
it uses the function "ftime" and the millisecond field is ignored.
All the examples in the winsup testsuite also generally check to 5 seconds only.
Is there any in
21 matches
Mail list logo
