World Wine News

WHAT'S NEW with Wine-20040813: (see ChangeLog for details)

• New msiexec application.
• Support for alpha blending.
• More sound support improvements.
• Various code cleanups.
• Lots of bug fixes.

Tom Wickline updated the status pages , including the addition of builtin versions of atl.dll, d3dxof.dll, dbghelp.dll, and mlang.dll. Our janitorial projects received a bit of their own janitorial clean up courtesy of Dimi Paun. They also saw the addition of -Wsign-compare as a useful gcc warning to turn on (suggested by Mike McCormack.) Finally, over on the downloads page we've added Fedora Core 2 and White Box Enterprise Linux targets as part of the Red Hat packages maintained by Vincent Béron.

I propose the addition of this new debug tool that will allow developers to output backtraces to the console, without having to interact with a debugger. It can give a useful indication of how functions are being called in situations where a break point is not appropriate. To use it, simply include "wine/backtrace.h" somewhere and then call dump_backtrace(), which will generate an output similar to the following:

Backtrace:

0xffffe40e
NTDLL_wait_for_multiple_objects+0x103
NtWaitForMultipleObjects+0x50
WaitForMultipleObjectsEx+0xa3
WaitForSingleObject+0x36
dump_backtrace+0x4c
InternetConnectW+0xf9
InternetConnectA+0x115
winapi_test+0x12f
func_http+0x1a
run_test+0x62
__wine_exe_main+0x163
start_process+0xc3
wine_switch_to_stack+0x11

I am not 100% sure how the patch that Robert's proposing would work in practice, but I can tell you (from working with Java for a long time now) that having readily available backtraces is invaluable.

I for one love backtraces, but on the other hand I don't much care for debuggers. Having access to them without being forced to go through the debugger would be much appreciated.

Ditto.

Wine has always had massive problems with getting easily accessible debugging/diag support (doing debugging stuff IS hard, no question here...). Thus I think we generally want not less, but more support, as long as it helps (and as long as it doesn't cause a maintenance headache or ill-maintained subsystems due to too much "choice" in debugging options...). Since I'd think that that backtrace code should be fairly small and self-maintaining, I'd vote for including it.

In Java you can say this:

new Exception().printBackTrace();

or some equivalent to get a printout of where you are, and it's very convenient.

I can see the reasoning behind keeping the code in the debugger then triggering it using a custom exception though, as that way we only have one piece of backtracing code.

My problem with this approach is that it relies on the exception actually getting through to the debugger instead of being trapped by the program code and swallowed. I guess we could install a vectored handler to boot the debugger and such but now the code is a lot more complex and confusing for newbies than just having some inline functions in the headers. As if the SEH code wasn't already confusing enough!

I'm sure every semi-involved Wine developer can imagine dozens of "reasons of the day" why winedbg doesn't launch properly on error again... Failure in wine exception handling code, failure to look up winedbg (both registry and disk), failure to pass winedbg cmdline parameters properly, failure to get winedbg started up properly, failure to get winedbg to parse the current modules and stack frame properly, ...

That's why a "no frills" debugging mechanism is a good idea IMHO.

P.S.: no offense to Eric. He's done TONS of very useful things to winedbg, and when considering how many fatal architecture changes winedbg had to go through, it's amazing that it still works pretty well. :-)

Microsoft Research has released a Shared Source version of the game Allegiance. This is a hefty 512 meg download and of course the license that it is under would prevent anyone from sharing the changes but this would really allow us to improve Winelib by porting such a massive game.

http://research.microsoft.com/research/allegiance/

Grab your copy quick before they pull it down.

The classic Unix way to wait for I/O events on multiple file descriptors is with the select() and poll() system calls. When a process invokes one of those calls, the kernel goes through the list of interesting file descriptors, checks to see if non-blocking I/O is available on any of them, and adds the calling process to a wait queue for each file descriptor that would block. This implementation works reasonably well when the number of file descriptors is small. But if a process is managing thousands of file descriptors, the select() and poll() calls must check every single one of them, and add the calling process to thousands of wait queues. For every single call. Needless to say, this approach does not scale very well.

I have a program (a server) that has a very large number of synchronization constructs. Even when everything is idle there, wineserver is taking 60% of the CPU, raising load average to 2.4. When load is applied, response time occasionally jumps from tenths of a second to two minutes.

I noticed that in server/fd.c, the wineserver is using "poll" to select between file descriptors. The application is going through this code over 2000 times a second, with over 380 file descriptors each time. I am wondering whether this can be the cause of the slowdown.

One of the possible solutions to this would be to use epoll instead. This, of course, would have to be backed by a configure check, as not all systems for which wine is intended support epoll. Another, arguably better, solution would be to use libevent for this purpose. Libevent has the distinct advantage that it automatically chooses the best tool for the job (epoll, poll, /dev/poll, or if all else fails, select). However, if there is another, independent use of poll, porting the semantics to libevent may prove non-trivial.

So what does the forum think?

One last question. What are the "users"? What constructs cause a new file descriptor to be allocated in the wineserver?

By all means, let's try epoll.

FWIW, I wrote a wrapper layer that illustrates how to detect whether epoll etc. are available. I'm convinced that runtime detection is the only way to go. Compile time detection is insufficient. My code is at http://kegel.com/rn If you actually try to use it, let me know. I expect it might be useful mostly as a guide. It's edge-trigger oriented, but you can trivially add the flag (or remove the flag) needed to get level-triggered behavior again if you really need it. I highly recommend using edge-triggered behavior, though.

"potential race conditions" is the wrong way to think about it, really.

Switching to edge triggered epoll from select() or poll() is always an interesting intellectual challenge; you're fundamentally switching to an idiom where the app has to remember more than it did before. Once you've done it a few times, it gets easier.

If I have time, I'll have a look at the state machine inside wineserver and see how tricky it'd be.

this is a nice little posting from the Con Kolivas Linux interactivity patches list. Note that it is about Cedega, not Wine, but it might easily affect Wine, too.

Are we doing some big no-nos in the threading area here? (or maybe it's just done the way it is because we cannot do it a different, better way?)

For the whole discussion, please see

http://bhhdoa.org.au/pipermail/ck/2004-August/000428.html

It's in fact as you say, all parts of wine have different priorities, and some of them are higher than X

After renicing all of them there is no problem with choppy sound in all of time wasting programs I've on my disk :>, and overall (subjective) performance is better of course.