This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


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

__fwalk mutex problem


Hello,

The __fwalk and __fwalk_reent functions lock the file mutex before calling the walk function. They unlock the mutex when the function returns.

  for (g = &ptr->__sglue; g != NULL; g = g->_next)
    for (fp = g->_iobs, n = g->_niobs; --n >= 0; fp++)
      if (fp->_flags != 0)
        {
          _flockfile (fp);
          if (fp->_flags != 0 && fp->_file != -1)
            ret |= (*function) (fp);
          _funlockfile (fp);
        }

When you call __fwalk(ptr, fclose), as _cleanup_r does, there is a problem because fclose will release the mutex. When the function returns __fwalk will call _funlockfile on a file that is closed.

With our mutex implementation that gives an error, because a released mutex is flagged as invalid.

Is it necessary for __fwalk to lock the file before calling the walk function? When __fwalk is called with fclose and fflush it seems unnecessary, because both of those functions lock the mutex internally.

In __srefill_r there is a call to _fwalk with lflush as the walk function. It calls fflush after inspecting fp->_flags, is the lock needed in this case? If so lflush could be modified to lock the file internally.

(There is also __fp_lock_all and __fp_unlock_all to consider. I am not sure how these are used though, couldn't find a reference anywhere).

Cheers,
 Hans-Erik Floryd




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