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]

Locking in flush(0) and other flushall ops


Hi!

fflush(0) nor _flushlbf() does not do any locking which means fflush(0)
cannot be used in multi-threaded programs etc.
This has two problems:
a) the _IO_list_all chain may shrink or grow while we're walking over it
   (growing should not cause problems, shrinking will)
b) the calls to _OVERFLOW() are not done with the file descriptor lock held

To complicate things even more, _IO_new_file_underflow calls
_IO_flush_all_linebuffered from its underflow routine, perhaps with that
file's lock already held.

It is clear that it needs some kind of locking, the question is which to
avoid deadlocks.
E.g. can overflow handler (which may be user provided) do an fopen/fclose
for some or something else that will result in _IO_link_in or _IO_un_link?
If not, _IO_flush_all/_IO_flush_all_linebuffered could acquire list_all_lock
at start and release it at end (together with a cleanup handler
installation/removal). But still those routines should probably try to
acquire individual file mutices (which means _IO_new_file_underflow will need
to set some special flag which will cause _IO_flush_all_linebuffered to
ignore acquiring that mutex). There is the possibility that
_IO_new_file_underflow happens several times at once, so it is possible
_IO_flush_all_linebuffered will skip several files.
If overflow is allowed to do something which will in turn do _IO_link_in or
_IO_un_link, things will be even more complicated.

Ideas?

	Jakub


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