http://bugs.winehq.org/show_bug.cgi?id=24044
--- Comment #8 from Anastasius Focht focht@gmx.net 2010-08-20 07:49:25 --- Hello again,
well I came to conclusion this is an app multithreading bug (race) exposed by different thread timing (execution profile) between Windows and Linux.
Although the icq plugin commits lots of setting changes initially, triggering the flushes, it should be done after a certain amount of time and not recurring in so fast intervals (except if the server packet loop brings back large amount of change data which triggers settings write again).
http://miranda.googlecode.com/files/miranda-im-v0.8.27-src.zip http://miranda.googlecode.com/files/miranda-im-v0.8.27-unicode-pdb.zip
dbx_mmap plugin source: miranda\plugins\db3x_mmap ICQ plugin source: miranda\protocols\IcqOscarJ\
I previously posted the snippet, hence again when looking from "multithreaded" perspective creating and killing timers in that way this is rather bad and prone races (flushBuffersTimerId is not guarded in any way!): Due to races, some of the created "flush" timers might escape destruction and continue to be "free running", resulting in cpu load.
--- snip --- static UINT_PTR flushBuffersTimerId;
static VOID CALLBACK DoBufferFlushTimerProc(HWND hwnd, UINT message, UINT_PTR idEvent, DWORD dwTime) { if (!pDbCache) return;
KillTimer(NULL,flushBuffersTimerId); log0("tflush1"); if (FlushViewOfFile(pDbCache, 0) == 0) DatabaseCorruption(NULL); log0("tflush2"); }
void DBFlush(int setting) { if(!setting) { log0("nflush1"); if(safetyMode && pDbCache) { if (FlushViewOfFile(pDbCache, 0) == 0) DatabaseCorruption(NULL); } log0("nflush2"); return; } KillTimer(NULL,flushBuffersTimerId);
flushBuffersTimerId=SetTimer(NULL,flushBuffersTimerId,50,DoBufferFlushTimerProc); } --- snip ---
Using a critical section should cure this (maybe the already present "csDbAccess" one).
Regards