Huang, Zhangrong wrote:
Hi,
2008/7/3 Maarten Lankhorst m.b.lankhorst@gmail.com:
Hello, I think that is a bad idea, while there might be 1 or 2 real genuine uses for only throwing an exception while debugging, 99% of the time it's really wine deadlocking itself, it's wine's own fault and I would rather see the backtraces of the deadlock rather then the app hanging forever.
OK, my thoughts:
- A patch for Wine that throws exception for Wine internal locks only
when debug is present, so after waiting for 65 seconds, some apps don't crash. Of course if you run app under debugger, you get exception to check deadlock.
- Another patch to implement the missing timeout feature, Wine checks
the timeout value NtCurrentTeb()->Peb->CriticalSectionTimeout which comes from registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\CriticalSectionTimeout, then throws EXCEPTION_POSSIBLE_DEADLOCK.. So if you want to check deadlock, setting the registry value to 30 seconds or 60 seconds or any value you want.
I personally prefer setting a flag of some sort. Also have someway of preventing wine from locking.. So option 2 looks better to me than option one.. option one can cause some confusion. Also have the time out added to the winecfg and have it manage the registry.
While we are at it =D Since I read that its possible to set the wine debug flags in the registry (I don't remember where I read it on winehq) why not have a tab in winecfg (or in the pannels that the gentleman is working on for the summer of code) which lets you have check boxes with all the flags on it to set the registry. Divide it up even into these are wine internal flags.. these are win flags etc... still provide for the WINEDEBUG=+relay etc facility..
Second thought : Where would I put in a feature request to tell the various trace channels to send to a log file or pipe instead of having to manually pipe it... that way others could write tools that listen on the pipe to write debuging utilities....
Just my 2cp
Chris