apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: [PATCH] Regarding semun definition in proc_mutex.h
Date Thu, 27 Jun 2002 20:10:31 GMT
At 02:17 PM 6/27/2002, Jim Jagielski wrote:
>I'm still slogging through tons of email, but was the issue that
>it was simply 'long' instead of 'int' (and trusting that the platform/OS
>correctly handles things) or that we require a specific physical

Ours is simply a HANDLE.  End of issue for this platform :-)

>FWIW, the current 2.0 implementation is copied from 1.3, so if it's
>wrong in one, it's wrong in the other. Also, in other implementations
>I've seen, it's always used 'int' and not 'long' so the current
>usage seems wrong to me. :/

Agreed, for this type.  Just making a 32/64 bit ambiguity observation :-)

>At 1:11 PM -0500 6/27/02, William A. Rowe, Jr. wrote:
> >At 01:00 PM 6/27/2002, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> >>Yep - with HP-UX running on 64-bit Itanium, and using the 64-bit data 
> model.
> >>The side effect of having the "long val" in the union definition is that
> >>it'll have corrupted the mutex/semaphore while creating the proc_mutex
> >>itself (proc_mutex_sysv_create). On HP-UX, the symptom was that the
> >>listener_thread hangs while doing a SAFE_ACCEPT.
> >
> >AFAICT, the only exception is win32, which retains the 32 bit int, 64 
> bit memory
> >pointer, 64 bit 'INT_PTR' meaning that it could wrap an int or pointer.
> >
> >This appears to apply to _NO_ unix architectures, so int should be correct.
> >We could create an ap_intptr_t that does the same, with;
> >
> >typedef union ap_intptr_t {
> >    int i;
> >    int *p;
> >} ap_intptr_t;
> >
> >and take ap_intptr_t or sizeof(ap_intptr_t) when we need an object
> >that safely maps either and both.
> >
> >Bill
>    Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
>       "A society that will trade a little liberty for a little order
>              will lose both and deserve neither" - T.Jefferson

View raw message