December 2005 - Wine-Devel - list.winehq.org

Re: Unable to start UTF-8 encoded executable in UTF-8 locale - one line fix included

by mengzhuo li

i m very glad to know someone notice almost the same problem. as u said , i found the function open_builtin_exe_file called in some different callers, and in these callers all the variable file_exists uninitialized . so there r 2 methods to solve the problem . one is initialize all the variable file_exists 0 when they r defined . the other is as u said . initialize in the callee. as the problem , from the codes i can understand if start UTF-8 encoded executable in UTF-8 locale , it will crash. but i havent the enviroment, i havent a .UTF-8 encoded executable . so just report the direct problem on my machine. --------------------------------- 无限容量雅虎相册，原图等大下载，超快速度，赶快抢注！

Dec. 1, 2005

Re: Debugging Critical Section lockups

by Robert Shearman

David D. Hagood wrote: > Robert Shearman wrote: > >> David D. Hagood wrote: >> > >> >> Unless the installer is using TryEnterCriticalSection, I would expect >> CPU utilisation to be 0% when deadlocking. > > > Yes, *once the deadlock occurs* the CPU drops to 0%. The issue (I > think) is more along the lines of this: > > On fast CPU: > > thread 1 locks resource A, does something, locks B, unlocks B, unlocks A. > > Thread 2 locks B, does something, locks A, does something, unlocks C, A. > > On slow machine: > > Thread 1 locks resource A, does something. > > Context switch. > > Thread 2 locks B, does something. > > Context switch > > Thread 1 tries to lock B and blocks. > > Context switch. > > Thread 2 tries to lock A and blocks. > > Deadlock. > > In other words, on the fast CPU the deadlock does not happen because > thread 1 gets everything done before thread 2 starts. On the slow > machine, thread 2 starts while thread 1 is still doing stuff. Yep, example of what not to do in concurrent programming. You should make a note of the order in which locks are taken and always take the locks in that order and always release them in the opposite order. You have several options from here: 1. File a bug report with the maker of the application. 2. Find a function that B uses just before it locks that A doesn't use and add a Sleep call. Obviously this kind of fix won't be accepted into Wine. 3. Do tests to try to find a function that A uses that is much slower on Wine and try to fix it. -- Rob Shearman

Dec. 1, 2005

Re: Debugging Critical Section lockups

by David D. Hagood

Robert Shearman wrote: > David D. Hagood wrote: > > > Unless the installer is using TryEnterCriticalSection, I would expect > CPU utilisation to be 0% when deadlocking. Yes, *once the deadlock occurs* the CPU drops to 0%. The issue (I think) is more along the lines of this: On fast CPU: thread 1 locks resource A, does something, locks B, unlocks B, unlocks A. Thread 2 locks B, does something, locks A, does something, unlocks C, A. On slow machine: Thread 1 locks resource A, does something. Context switch. Thread 2 locks B, does something. Context switch Thread 1 tries to lock B and blocks. Context switch. Thread 2 tries to lock A and blocks. Deadlock. In other words, on the fast CPU the deadlock does not happen because thread 1 gets everything done before thread 2 starts. On the slow machine, thread 2 starts while thread 1 is still doing stuff.

Dec. 1, 2005