_sim_debug_flush(): Use fsync(). #454
Conversation
bscottm
force-pushed
the
debug_flush_loop
branch
from
7df5086 to
e6a4d44
Compare
|
I'm a bit confused here. You pointed out that the simulated fsync can't be used in multithreaded simh. So why is it still in the code? If it's broken, would it not be more logical to remove it, especially since everyone has fsync? |
It can still be used for single threaded code, i.e., simulators that don't use AIO. Also, I don't have a good handle on which platforms SIMH is supposed to support (the Very happy to take it out and rewrite code to assume everyone has |
Fix race condition in _debug_fwrite_all() where the FILE *f output file can be permanently NULL, causing fwrite() to permanently return zero and resulting in an infinite loop on mulithreaded SIMH. This pathology primarily occurs when main thread calls flush_svc() and one of the Ethernet threads (reader, writer) emits debugging output. Linux and macOS platforms invoke fsync() to synchronize file data to disk. Windows has a fsync() wrapper calling _commit() providing the same semantics. Issue traced to _sim_debug_flush() calling sim_set_deboff(0, NULL) to simulate fsync().
bscottm
force-pushed
the
debug_flush_loop
branch
from
e6a4d44 to
2e6a571
Compare
@pkoning2: It's all just |
Fix race condition in _debug_fwrite_all() where the FILE *f output file can be permanently NULL, causing fwrite() to permanently return zero and resulting in an infinite loop on mulithreaded SIMH. This pathology primarily occurs when main thread calls flush_svc() and one of the Ethernet threads (reader, writer) emits debugging output.
Linux, macOS invoke fsync(). Windows invokes a fsync() wrapper that invokes _commit().
Issue traced to _sim_debug_flush() calling sim_set_deboff(0, NULL) to simulate fsync().