> On Jan 2, 2017, at 07:25, Pádraig Brady wrote:
>
> On 02/01/17 02:25, Assaf Gordon wrote:
>> Hello,
>>
>> Attached are four small bug fixes and two additions to the debug messages in
>> parse-datetime.y (used in 'date --debug').
>
> Please push.
Thank you for the review, pushed.
> I presu
On Tue, Jan 03, 2017 at 04:33:24PM -0800, Paul Eggert wrote:
> (An aside: It's typically safer in C to assign to a typed temporary than
> to cast to the type, as casts are too powerful. This is orthogonal to
> the long-vs-ptrdiff_t issue.)
Yes.
Sometimes, to make casts safer, I declare macros to
On Wednesday, January 4, 2017 3:17:01 PM CET Bruno Haible wrote:
> Pádraig Brady:
> > Now that test-lock.c is relatively fast on numa/multicore systems,
> > it seems like it would be useful to first alarm(30) or something
> > to protect against infinite hangs?
>
> If we could not pinpoint the orig
Pavel Raiskup wrote:
> As gnulib is portability library, it would be probably nice if gnulib
> automatically set appropriate policy according to actual specifications (even
> if
> we had to set the policy by non-portable calls).
The 2-2.c test shows that it still fails, even if the right policy i
Pádraig Brady:
> Now that test-lock.c is relatively fast on numa/multicore systems,
> it seems like it would be useful to first alarm(30) or something
> to protect against infinite hangs?
If we could not pinpoint the origin of the problem, I agree, an alarm(30)
would be the right thing to prevent
On Wednesday, January 4, 2017 1:19:36 PM CET Pavel Raiskup wrote:
> I don't want to claim rwlocks are not reliable. IMO rwlocks do what we
> ask to do... One writer OR multiple readers.
>
> The question is what should be the default policy ... who should be more
> privileged by default (writers
Hi Bruno,
On Wednesday, January 4, 2017 11:54:27 AM CET Bruno Haible wrote:
> Hi Pavel,
>
> > Can we assume all systems supporting pthreads are conforming to this
> > specs? That was pretty big (and pretty recent) change of specification.
>
> The change in the specification [4] mentions that th
> and it points to two tests from the Linux test project [5][6]. Can you run
> these tests on your Koji system?
For me, these two tests fail on a glibc-2.23 system:
$ wget
https://raw.githubusercontent.com/linux-test-project/ltp/master/testcases/open_posix_testsuite/conformance/interfaces/pthrea
On 04/01/17 10:54, Bruno Haible wrote:
> Hi Pavel,
>
>> Can we assume all systems supporting pthreads are conforming to this
>> specs? That was pretty big (and pretty recent) change of specification.
>
> The change in the specification [4] mentions that the issue arose with glibc,
> and it point
Hi Pavel,
> Can we assume all systems supporting pthreads are conforming to this
> specs? That was pretty big (and pretty recent) change of specification.
The change in the specification [4] mentions that the issue arose with glibc,
and it points to two tests from the Linux test project [5][6].
On Wednesday, January 4, 2017 12:43:17 AM CET Bruno Haible wrote:
> Pavel Raiskup wrote:
> > POSIX says (for pthread_rwlock_wrlock()):
> >
> > Implementations may favor writers over readers to avoid writer
> > starvation.
> >
> > But that's too far from 'shall favor' spelling.
>
> You must
11 matches
Mail list logo
