|View Issue Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000349||mercury||Bug||public||2014-07-22 15:44||2014-07-28 15:48|
|Target Version||Fixed in Version|
|Summary||0000349: io stream predicates thread-safe or not|
|Description||Programs 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.
|Tags||No tags attached.|
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.
|2014-07-22 15:44||wangp||New Issue|
|2014-07-28 15:48||wangp||Note Added: 0000751|