This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: PTHREAD_COND_INITIALIZER
Hi!
Tuesday, 25 September, 2001 Robert Collins robert.collins@itdomain.com.au wrote:
>> RC> Yes. Null is returned by calloc(), so users may unintentionally submit
>> RC> PTHREAD_COND_INITIALIZER when there is actually a bug in their program.
>> RC> Then they will wonder why their (say) shared memory stuff is compiling
>> RC> but not working.
>>
>> well, CreateEvent() too accepts NULL as last argument to create an
>> anonymous event. as numerous other win32 functions do. Personally, i
>> found this approach consistent. NULL is only pointer that's guaranteed
>> to not point to valid object. Everything else is system-dependent.
RC> Firstly, we do not need to cater for all systems - just
RC> win9x/Me/Nt/2K/XP in the 32-bit win32 subsystem.
this approach just adds more difficulties for whomever wanting to port
cygwin to win64, alpha, ppc, etc. Those are solvable problems, of course,
but i stand for not creating them in first place.
RC> Secondly, there are common features in both core platforms. I refer you
RC> to http://support.microsoft.com/directory/article.asp?ID=KB;EN-US;Q125691
RC> and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dngenlib/html/msdn_ntvmm.asp
RC> The combination indicate that an address between the 3 and 4 Gb limit
RC> will _never_ be a valid userspace address. So as long as we test for
RC> pointer equality in that range before checking for addressable memory,
RC> we are _guaranteed_ safety.
RC> Yes, the 0-4Mb space I used initially is not guaranteed safe under NT, I
RC> acknowledge that and agree it should be fixed.
RC> However I still do not agree on NULL. Using a non-null value is
RC> efectively free speed wise, and can help detect programmer errors.
RC> The difference between the CreateEvent style API and the pthreads API is
RC> that CreateEvent accepts and requires all the parameters to define event
RC> behaviour. The NULL you refer to is _simply_ the name. You are not
RC> allowed under teh CreateEvent to call SignalObjectAndWait (NULL, foo);
RC> Under pthreads you are allowed to do that - IFF PTHREAD_COND_INITIALIZER
RC> is used.
one shouldn't pass PTHREAD_*_INITIALIZERs as directly as parameters.
SUSv2 says they can be used as initializers for static data.
passing PTHREAD_COND_INITIALIZER directly to function is obvious
memory leak.
RC> That difference being that the INITIALIZER is always the
RC> default parameters. It's really a case of failing gracefully in the case
RC> of programmer idiocy, EINVAL is better than Q:"hey it works on 95, but
RC> not on NT" - why? A: on 95 you are getting NULL'd memory, but not on NT.
RC> (for example).
and those idiots who don't check for NULL return from malloc won't
check for EINVAL either.
RC> I really don't see any benefit from using NULL in this instance, and I
RC> do see benefits from not using NULL.
the benefit from using NULL is portability. I understand that cygwin
is not supposed to that portable as, say, Apache, but nevertheless.
[...]
>> not too many, actually. a bunch of them do include "internal.h" but
>> doesn't use if for testing itself, but only for diagnostic output.
RC> Yes, and the internals are what they are debugging :]. *shrug*.
not always. for instance, in condvar2.c they do include internal.h,
but removing this dependency without disabling test functionality is
pretty easy. I'll check this stuff into cygwin testsuite tonight. it
needs just minor cleanup currently.
RC> http://users.bigpond.net.au/PthreadTest-0.1.tar.gz
HTTP error 404 :(
Egor. mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19