This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Speed up libio

On Fri, Aug 29, 2003 at 03:51:31PM +0200, Jakub Jelinek wrote:
> +# ifdef __EXCEPTIONS
> +#  define _IO_acquire_lock(_fp) \
> +  do {								      \
> +    auto inline __attribute__((always_inline)) void			      \
> +    _IO_acquire_lock_fct (int *p __attribute__ ((__unused__)))	      \
> +      {								      \
> +	if (((_fp)->_flags & _IO_USER_LOCK) == 0)			      \
> +	  _IO_funlockfile (_fp);					      \
> +      }								      \
> +    int _IO_acquire_lock_dummy					      \
> +      __attribute__ ((cleanup (_IO_acquire_lock_fct)));		      \
> +    _IO_flockfile (_fp)
> +
> +# else
> +#  define _IO_acquire_lock(_fp) _IO_acquire_lock_needs_exceptions_enabled
> +# endif
> +# define _IO_release_lock(_fp) ; } while (0)

Seems like it'd be a bit cleaner like

static inline void
_IO_acquire_lock_fct (FILE **p)
{
  FILE *fp = *p;
  if ((fp->_flags & _IO_USER_LOCK) == 0)
    _IO_funlockfile (fp);
}

#define _IO_acquire_lock(_fp)					\
  do {								\
    FILE *_IO_acquire_lock_file					\
	__attribute__((cleanup (_IO_acquire_lock_fct)))		\
	= (_fp);
    _IO_flockfile (_IO_acquire_lock_file);


I see no reason to invoke nested functions here...


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