When an schannel reader/writer synchronise, Felix previously made it indeterminate which one proceeded first.
The actually implementation continued on with which ever made the last request, i.e. the one allowing the synchronisation. The other fthread was pushed on the active list. This is changed. Now, the reader is specified to gain control after a synchronisation. The reason is that if the write supplies a pointer to data the reader should acquire, but then continues first after meeting the reader, it may modify the data before the reader has a chance to acquire it, typically to copy it. in particular, this problem manifested in rt-1.01.23-1, where a simple producer consumer pair failed to exchange the data correctly. This only occurred now with the new collector, somehow because the data became prematurely unreachable, was deleted, and then the same block got re-allocated. This can happen because the data is heaped before the service call is issued, which can trigger a collection prior to the allocation. Valgrind noted the problem, but the program always worked under valgrind because it circulates blocks, whereas the standard malloc probably re-issues the most recently free'd block. At this point, only the faio tests appear to be failing with rigorous "collect every single allocation" testing. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
