This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: cygwin/newlib types patchs


"J. Johnston" wrote:
> 
> Joel Sherrill wrote:
> >
> > Joel Sherrill wrote:
> > >
> > > Just to make sure I understand .. What you intend to do for
> > > structure is effectively this:
> > >
> > > #ifdef __RTEMS_INSIDE__
> > > typedef struct {
> > >   int is_initialized;
> > >   void *stackaddr;
> > >   int stacksize;
> > >   int contentionscope;
> > >   int inheritsched;
> > >   int schedpolicy;
> > >   struct sched_param schedparam;
> > >
> > >   /* P1003.4b/D8, p. 54 adds cputime_clock_allowed attribute.  */
> > > #if defined(_POSIX_THREAD_CPUTIME)
> > >   int  cputime_clock_allowed;  /* see time.h */
> > > #endif
> > >   int  detachstate;
> > >
> > > } pthread_attr_t;
> > > #else /* in user land */
> > > typedef void * pthread_attr_t;
> > > #endif
> > >
> > > If this is not the case, then I need to be educated further to make
> > > an intelligent decision. :)
> > >
> > > --joel
> >
> > Something just bothered me... from opengroup.org
> >
> >      #include <pthread.h>
> >      int pthread_attr_init(pthread_attr_t *attr);
> >
> >      int pthread_attr_destroy(pthread_attr_t *attr);
> >
> > Shouldn't I be able to write this code?
> >
> > {
> >   pthread_attr_t my_attr;
> >   pthread_attr_init( &my_attr );
> > }
> >
> > The RTEMS implementation assumes that the user is providing the memory
> > for the structure.  If you change the user view so pthread_attr_t is
> > a void *, we break.
> >
> > On types like pthread_t, RTEMS is really a unsigned 32 bit integer
> > and we again assume that the user is providing that space.
> >
> > Not letting the user know the size is broken for us.  I agree that it is
> > certainly
> > bad form for them to look inside.
> >
> 
> After thinking a little further on this, IMO it is best to separate out the pthread types from
> sys/types.h since they are extremely system-specific.  This is how glibc handles it.  So, we have a
> separate header: sys/pthreadtypes.h which contains the pthread types.  A default header file will
> exist in the libc/include/sys directory, however, each system that supports pthreads will have its
> own version of sys/pthreadtypes.h in their sys directory which will override the default.

OK.  All I ask is that whoever does this be aware that RTEMS does use
these as they
are now and they are correct for RTEMS.  Whatever you do, please try to
account for
an RTEMS specific sys/pthreadtypes.h (or make sure the default one is
RTEMS-friendly :).
 
> If a system wants to hide the internals they can use anonymous field names or structs simply padded
> to the appropriate size which allows the user-scenario above.  FWIW: glibc doesn't seem to worry
> about it and exposes the structs.

It seemed like a pain when we implemented this for RTEMS.  Hiding the
internals
seems to require more work to implement and maintain.  Moreover, our
thought
path also included that going the void * route forces routines like 
pthread_attr_init to do more dynamic memory allocation which is
generally
a bad thing in embedded systems.

Please leave them exposed for RTEMS.  

> -- Jeff J.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]