[patch] Symbolic value for PTHREAD_MUTEX_DEFAULT
Hi,
As discussed with Robert Collins, I propose this patch to make
the 'default' mutex type more explicit.
2002-12-05 Christophe Galerne [EMAIL PROTECTED]
* pthread.h (PTHREAD_MUTEX_DEFAULT):
reorder PTHREAD_MUTEX_DEFAULT and PTHREAD_MUTEX_RECURSIVE so that
PTHREAD_MUTEX_DEFAULT can be defined as PTHREAD_MUTEX_RECURSIVE.
add a comment that PTHREAD_MUTEX_NORMAL is not yet implemented.
? pthread_constant.patch
Index: pthread.h
===
RCS file: /cvs/src/src/winsup/cygwin/include/pthread.h,v
retrieving revision 1.12
diff -u -p -r1.12 pthread.h
--- pthread.h 4 Jul 2002 14:17:30 - 1.12
+++ pthread.h 6 Dec 2002 22:55:18 -
@@ -50,12 +50,15 @@ extern C
#define PTHREAD_CREATE_JOINABLE 0
#define PTHREAD_EXPLICIT_SCHED 1
#define PTHREAD_INHERIT_SCHED 0
-#define PTHREAD_MUTEX_DEFAULT 0
+
+#define PTHREAD_MUTEX_RECURSIVE 0
#define PTHREAD_MUTEX_ERRORCHECK 1
+/* not implemented yet */
#define PTHREAD_MUTEX_NORMAL 2
+#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_RECURSIVE
+
/* this should be too low to ever be a valid address */
#define PTHREAD_MUTEX_INITIALIZER (void *)20
-#define PTHREAD_MUTEX_RECURSIVE 0
#define PTHREAD_ONCE_INIT { PTHREAD_MUTEX_INITIALIZER, 0 }
#define PTHREAD_PRIO_INHERIT
#define PTHREAD_PRIO_NONE
@@ -103,7 +106,7 @@ void pthread_cleanup_push (void (*routin
void pthread_cleanup_pop (int execute);
*/
typedef void (*__cleanup_routine_type) (void *);
-typedef struct _pthread_cleanup_handler
+typedef struct _pthread_cleanup_handler
{
__cleanup_routine_type function;
void *arg;
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: pthread_mutex_trylock does not lock
Robert Collins wrote: On Tue, 2002-12-03 at 23:06, Chris Knight wrote: Hello Rob, I have changed the code, see below. I now set the type to PTHREAD_MUTEX_NORMAL but that also does not block. The only documentation on cygwin threads say this is the same as PTHREAD_MUTEX_FAST_NP What documentation says that? This www.opengroup.org/onlinepubs/7908799/xsh/pthread_mutexattr_settype.html seems to explain that a PT_MUTEX_NORMAL mutex should behave the way Chris expect. If this doc is out-of-date, could you give a pointer to a more accurate source? We don't support NONRECURSIVE mutex's. I don't know what you mean by NORECURSIVE threads. Then maybe one should add a comment above pthread.h(55): #define PTHREAD_MUTEX_NORMAL 2 that this option is not supported. Also above pthread.h(57): #define PTHREAD_MUTEX_INITIALIZER (void *)20 a comment that says that a default MUTEX will be recursive might avoid some surprise. =:-D Thanks, Christophe PS: Could you cc me as I am not on the list? Thanks. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pthread_mutex_trylock does not lock
Robert Collins wrote: On Thu, 2002-12-05 at 08:33, Christophe Galerne wrote: NB: PT_MUTEX_NORMAL is not a posix mutex type - it's PTHREAD_MUTEX_NORMAL Right that was a typo. Or you could check the return value from pthread_mutexattr_settype and see that it returns EINVAL. The thing is it's not really an invalid value for 'type' in the call. Maybe it would be better to break the compilation of programs that expect this value rather than have the developpers debug their applications before figuring it out. Come to think about it, I'm wondering if there was a policy of having the headers right first then the implementation or if headers and imlpementation came together. But that's maybe not the right maillist for that. =:-D Also above pthread.h(57): #define PTHREAD_MUTEX_INITIALIZER (void *)20 a comment that says that a default MUTEX will be recursive might avoid some surprise. =:-D Look at pthread.h:53 and pthread.h:58. DEFAULT is mapped to RECURSIVE That's a good point. Onather solution that might be considered more elegant would be to rearrange the defines to make the default behavior self-explanatory. Ex. #define PTHREAD_MUTEX_RECURSIVE 0 #define PTHREAD_MUTEX_ERRORCHECK 1 #define PTHREAD_MUTEX_NORMAL 2 #define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_RECURSIVE Christophe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pthread_mutex_trylock does not lock
Robert Collins wrote: I never said that PTHREAD_MUTEX_NORMAL does not block, I was challenging the apparent 'cygwin threads' documentation. Right, in a way my remarq was OT... =:-D Christophe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
IOV_MAX value
Hi, I am trying to compile the ACE framework on cygwin. One of the problem I have is that they are using arrays of size IOV_MAX on the stack. Since IOV_MAX is defined in limits.h as #define IOV_MAX (__INT_MAX__-1) that turns out to be problematic Looking on some other platforms I see that IOV_MAX is typically define to be [16, 1024]. So I just want to make sure that IOV_MAX is correctly defined. Thanks, Christophe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
