2024-11-23 20:28 AEDT
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000349mercuryBugpublic2014-07-22 15:442014-07-28 15:48
Reporterwangp 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0000349: io stream predicates thread-safe or not
DescriptionPrograms which use different streams in different threads should not be unnecessarily serialised on the global lock. But I think it's also quite likely that users write to the same stream, stdout or stderr, from different threads without explicit synchronisation. This can produce garbled output but it basically works, at least for testing, so I think it needs to be allowed.

The underlying I/O routines (probably) have their own locking, but we also perform our own bookkeeping, like line counts, with the protection of the global lock. To safely mark the io procedures as `thread_safe' then requires per-stream locks or perhaps the use of atomic operations.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000751

wangp (developer)

2014-07-28 15:48

 In POSIX and Windows, the stdio stream functions are thread-safe, protected by per-stream locks. The only extra book-keeping we actually do is the line number tracking. We do stuff like MR_line_number(*mf)++; without any synchronisation sometimes, which could be a problem but I think unlikely.

To solve it, we could acquire the stream lock manually with flockfile, call the *_unlocked function (where possible), update the line number while holding the stream lock, then call funlockfile.

MSVC has *_nolock functions but I don't see any functions to manually acquire the stream lock. We would probably need our own locks there.

It's probably not worth the effort.
+Notes

-Issue History
Date Modified Username Field Change
2014-07-22 15:44 wangp New Issue
2014-07-28 15:48 wangp Note Added: 0000751
+Issue History