Ulrich Eckhardt, le Mon 12 Oct 2009 22:15:59 +0200, a écrit :
> On Sunday 11 October 2009 12:11:50 Remi Denis-Courmont wrote:
> > I would expect cond_timedwait to sleep for the specified interval rather
> > than abort (though sleeping in a portable way is not completely trivial).
>
> Alternative s
On Sunday 11 October 2009 12:11:50 Remi Denis-Courmont wrote:
> I would expect cond_timedwait to sleep for the specified interval rather
> than abort (though sleeping in a portable way is not completely trivial).
Alternative suggestion: If pthread_cond_init() is implemented in the stubs to
return
On Sun, Oct 11, 2009 at 09:59:33PM +0200, Samuel Thibault wrote:
> Remi Denis-Courmont, le Sun 11 Oct 2009 12:11:50 +0200, a écrit :
> > - Message d'origine -
> > > Here is a patch that adds only pthread_condattr_init/destroy,
> > > pthread_cond_timedwait, pthread_exit, and makes both cond_
Remi Denis-Courmont, le Sun 11 Oct 2009 12:11:50 +0200, a écrit :
> - Message d'origine -
> > Here is a patch that adds only pthread_condattr_init/destroy,
> > pthread_cond_timedwait, pthread_exit, and makes both cond_*wait abort
> > instead of just returning 0.
>
> I would expect cond_tim
- Message d'origine -
> Hello,
>
> Here is a patch that adds only pthread_condattr_init/destroy,
> pthread_cond_timedwait, pthread_exit, and makes both cond_*wait abort
> instead of just returning 0.
I would expect cond_timedwait to sleep for the specified interval rather than
abort (thou
On Sun, Oct 11, 2009 at 01:23:57AM +0200, Samuel Thibault wrote:
> Here is a patch that adds only pthread_condattr_init/destroy,
> pthread_cond_timedwait, pthread_exit, and makes both cond_*wait abort
> instead of just returning 0.
[snip patch]
This set of additions seems reasonable to me.
- Josh
On Sat, Oct 10, 2009 at 4:23 PM, Samuel Thibault wrote:
> Here is a patch that adds only pthread_condattr_init/destroy,
> pthread_cond_timedwait, pthread_exit, and makes both cond_*wait abort
> instead of just returning 0.
Thanks! Reviewed, tested on glibc, and pushed.
Jamey
--
To UNSUBSCRIB
Jamey Sharp, le Thu 08 Oct 2009 14:37:54 -0700, a écrit :
> > I haven't seen any in the Debian packages yet, but I can very well
> > imagine that a library could want to protect itself from unexpected
> > cancellation from another thread of the application while doing
> > sensitive things.
>
> Tru
Hello,
Here is a patch that adds only pthread_condattr_init/destroy,
pthread_cond_timedwait, pthread_exit, and makes both cond_*wait abort
instead of just returning 0.
Samuel
diff -ur libpthread-stubs-0.1-orig/configure.ac
libpthread-stubs-0.1/configure.ac
--- libpthread-stubs-0.1-orig/configure
Jamey Sharp, le Thu 08 Oct 2009 14:37:54 -0700, a écrit :
> > At least pthread_cond_{init,destroy,wait,timedwait,signal} are used by
> > soci without systematically linking against -lpthread. I mostly added
> > the others to anticipate any use rather than waiting for build issues.
>
> I gather "s
On Thu, Oct 8, 2009 at 11:06 AM, Samuel Thibault wrote:
> Jamey Sharp, le Thu 08 Oct 2009 09:58:06 -0700, a écrit :
>> Here are some specific concerns, as well as which parts of the
>> proposal I approve of as-is.
>
> I quite generally do agree on them. I had just reproduced the glibc
> behavior.
Barton C Massey, le Thu 08 Oct 2009 14:03:55 -0700, a écrit :
> Jamey and I talked about this last week and IIRC we sort of
> decided that these patches are outside the intended scope of
> pthread-stubs. I think that any application linking against
> these functions should probably just link again
Jamey and I talked about this last week and IIRC we sort of
decided that these patches are outside the intended scope of
pthread-stubs. I think that any application linking against
these functions should probably just link against
libpthread.
So my vote is revert, I'm afraid.
We also talked abou
Hello,
Jamey Sharp, le Thu 08 Oct 2009 09:58:06 -0700, a écrit :
> It isn't obvious to me that most of the proposed additions are useful,
> which is why real use cases are important.
At least pthread_cond_{init,destroy,wait,timedwait,signal} are used by
soci without systematically linking against
On Thu, Oct 8, 2009 at 4:09 AM, Julien Danjou wrote:
> At 1253709699 time_t, Samuel Thibault wrote:
>> Here is an updated patch. Autoreconf needed of course.
>
> Can someone review this and say yes/no/wtf? :)
Sorry! I didn't notice this bug. Thanks for the reminder, Julien.
I'm not yet saying "n
At 1253709699 time_t, Samuel Thibault wrote:
> Here is an updated patch. Autoreconf needed of course.
Can someone review this and say yes/no/wtf? :)
--
Julien Danjou
// ᐰhttp://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
// Ferns will rule the world.
signature.
Hello,
Here is an updated patch. Autoreconf needed of course.
Samuel
diff -ur libpthread-stubs-0.1.backup/configure.ac
libpthread-stubs-0.1/configure.ac
--- libpthread-stubs-0.1.backup/configure.ac2006-11-22 08:51:21.0
+0100
+++ libpthread-stubs-0.1/configure.ac 2009-08-20 01:49:5
Tags 496715 + patch
thanks
Hello,
Here is a patch to implement it. Sources need to be re-autoconfed of
course.
Samuel
diff -ur libpthread-stubs-0.1.backup/configure.ac
libpthread-stubs-0.1/configure.ac
--- libpthread-stubs-0.1.backup/configure.ac2006-11-22 08:51:21.0
+0100
+++ lib
Package: libpthread-stubs
Severity: normal
Reading glibc's forward.c, libpthread-stubs should provide more
pthread_* functions, namely:
- pthread_attr_init, pthread_attr_destroy, pthread_attr_getdetachstate,
pthread_attr_setdetachstate, pthread_attr_getinheritsched,
pthread_attr_setinheritsch
19 matches
Mail list logo
