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] |
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] |