- Wine-Devel - list.winehq.org

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Gavriel State <gav(a)transgaming.com> writes: > Definitely a drawback, I agree. But the shared memory area could be relatively > high in the address space, so that a stray pointer is much more likely to run > into unmapped memory and segfault before overwriting crucial data. This is only one failure case, but there are many others; for instance stack corruption that causes the app to jump somewhere inside ReleaseMutex, which will then happily modify the right address in the wrong way. > The only way we're going to be able to get both speed and safety though is > to have some kernel support. While that's beyond the scope of what I'd like > to accomplish in the short term, I think that it's something worth thinking > about more. While the solution proposed by David Howells may be overkill, I'm > not sure that simply changing the communication mechanism as you suggested > (http://www.winehq.com/News/2000-37.html#0) will speed things up enough - > we'll still have the context switch overhead. The main problem is the TLB flush due to switching address spaces; but I don't see any way to avoid this if we want memory protection (which we definitely do). The only way to know if we can make it fast enough is to implement it and benchmark it... > At least in the case of mutexes, I believe that all we need to do is > make sure that the count field is always modified through interlocked > increment/decrement/etc including the wineserver. I think you underestimate the complexity of getting this right. For instance, how do you determine the address of the count field from the mutex handle, keeping in mind that handles can be manipulated from other threads or even other processes (cf. DuplicateHandle)? How do you cope with a thread dying in the middle of an operation? Of course you can ignore all these special cases, and it will even work most of the time. But it's clearly not a viable general solution... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Gavriel State <gav(a)transgaming.com> writes: > After some more thinking, Ove and I have come up with a mechanism that should eliminate > most of the wineserver overhead for mutexes and semaphores, without the need to resort > to a kernel module. We're probably going to give this a try over the next few days, so > any feedback will be very much appreciated. I don't see how you are going to make this work reliably. A basic design principle of the server is that no matter what a client process does, it cannot break either the server or other clients; given the number of bugs Windows apps contain, I feel this is very important. As soon as you introduce a shared memory area, you need the collaboration of all clients to ensure the stability of the whole system, since any client can corrupt system data structures. This is very bad. Also since the server is single-threaded its data structures don't need to be protected; but as soon as you manipulate them from multiple threads you need locking mechanisms, which will probably cost a lot in performance too. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: dlls/ntdll/debugtools.c patch
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Chris Morgan <cmorgan(a)wpi.edu> writes: > Resubmit of this patch. Alexander, is this patch ok? Looks good, but I wonder if we shouldn't add an assert() instead. People are not supposed to use the debug interface to print out huge strings, and printing partial lines messes up the output in multi-threaded programs. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Documentation fixes
by Patrik Stridvall Feb. 15, 2001

Feb. 15, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > More readable to a human, perhaps. > > Uh, yes, the source code is meant to be read by humans. winapi_check > is a nice tool but it doesn't justify making the code less readable; Sure but grouping all the variants together doesn't nessary make it less readable to human. It entirely depends on how diffrent the variants are. If for example one variant is an optimized i386 assembler variant and the other is a pure C variant it might be more sensible to group them together, in order to more make people making changes remember to change the other variant. In this case, I personally didn't find either way preferable so I did what was best for winapi_check. > instead it should be fixed to understand the existing constructs That is a quite complicated in this case. > (or > at least don't complain about them). OK. I can easily make it ignore multiple definitions. I will do that.

1 0

Re: Documentation fixes
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > More readable to a human, perhaps. Uh, yes, the source code is meant to be read by humans. winapi_check is a nice tool but it doesn't justify making the code less readable; instead it should be fixed to understand the existing constructs (or at least don't complain about them). -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: howto use dll´s in C
by christian richter Feb. 15, 2001

Feb. 15, 2001

Thanks, specmaker could use the dll, but i tried specmaker with severall dll´s and there were only four functions: unload_class, registerServer unregisterServer or something like that, i heared this is because of the COM,ActiveX nature of the dll´s ... can i use those classes in C ??? how,is it maybe possible with corba ? -----Ursprüngliche Nachricht----- Von: Jon Griffiths [mailto:tntjpgriff(a)tsnxt.co.uk] Gesendet: Mittwoch, 14. Februar 2001 14:45 An: christian richter; 'wine-devel(a)winehq.com' Betreff: Re: howto use dll´s in C Hi, If you have the wine sources, or browse them from www.winehq.com, checkout tools/specmaker/README. Also see the Winelib developer guide for details on Winelib in general. Note that if all you want is the string routines, thats a lot of overhead for a few routines. You might find they are available in source form from somewhere else. Cheers, Jon -- "Don't wait for the seas to part, or messiahs to come, Dont you sit around and waste this chance ..." -Live tntjpgriff(a)tsnxt.co.uk , jon_p_griffiths(a)yahoo.com

2 1

Speeding up wineserver syncronization objects with shared memory
by Gavriel State Feb. 15, 2001

Feb. 15, 2001

Hi everyone, We've recently been working on getting American McGee's Alice (a visually stunning game, if you haven't seen it before) running well under Wine, and we've run into a serious speed issue with synchronization objects like Mutexes. Currently, Alice runs at about 50% the framerate it gets in Windows with the same graphics driver (NVidia). When we started investigating, it turned out that the reason for this is that it's spending half of it's time in the WineServer. At first we assumed that this was due to the fact that the GL thunks need to grab the X11 lock. We realized that this wasn't necessary for most GL calls if we're using a direct rendering GL implementation, and turned off the locks. There was no effect - because there really wasn't much contention for the x11 lock. After going through a number of similar Wine internal possibilities and getting nowhere, we finally realized that the problem was the app itself. It's grabbing and releasing a mutex of it's own bazillions of times each frame. Since there's nothing much we can do about that we started thinking about the proposed linux kernel module approach. After re-reading the thread and looking over the prototype, I have to concur with Alexandre's judgement - the prototype that exists is trying to do too much work. After some more thinking, Ove and I have come up with a mechanism that should eliminate most of the wineserver overhead for mutexes and semaphores, without the need to resort to a kernel module. We're probably going to give this a try over the next few days, so any feedback will be very much appreciated. Here's what we've been discussing in private email: ============================================================================================ Ove writes: > Gav writes: > > > Alternatively, I wonder if there's some way to speed up synchronization stuff > > through the use of some kind of shared memory area that all wine processes know > > about. The shared memory area could be used to do mutexes with atomic test-and- > > set operations. > > Maybe. But we probably don't want extensive busy waits, so we'd need to > call the wineserver when we need to wait. And the wineserver isn't really > designed to do bus-locked atomic access to such shared areas itself. But > perhaps with some client cooperation... in win32, a mutex is just a > different (and slower) kind of a critical section, anyway (but since it's > handle-based it can work across address spaces). > > If each mutex had a wcount field shared among all clients, we could do... > > ReleaseMutex: > wc = InterlockedDecrement(&wcount) > if wc > 0 > call wineserver's ReleaseMutex > > WaitForSingleObject: > wc = InterlockedIncrement(&wcount) > if wc < 0 > return WAIT_OBJECT_0 > call wineserver's WaitForSingleObject > > which would at least do something about the > ReleaseMutex/WaitForSingleObject pairs in the same thread... That's exactly the kind of thing I was thinking about. We can probably do the same for the CriticalSection semaphores as well. I don't think that we can do anything to speed up Events though. So the next question is: what's the best way to manage the shared area for each mutex/semaphore? We could just expose the wineserver handle table directly in the shared memory area, expanding the handle_entry struct in the server with a DWORD to server as the count field. Theoretically it brings up security concerns, but I don't think that we care that much at this point. ============================================================================================ Thoughts, anyone? -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

1 0

RE: Documentation fixes
by Patrik Stridvall Feb. 15, 2001

Feb. 15, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > * dlls/winedos/dosvm.c, > > dlls/winedos/module.c: > > - Added documentation > > - Reorganized the no-DOS support. > > I don't think adding a #ifdef around each function is a good > idea. It's much more readable with a single #ifdef around the whole > file IMO. More readable to a human, perhaps. I'm not sure that I agree, but I don't really care much either way. Let me explain why I did it insteed. Currently winapi_check tried to check whether API functions have the correct inline documentation and the future some other application will generate the .spec files from inline documentation and function prototype. In order to be able to easily do this, it is IMHO much better if all the compile time depend variants is groups together in some standardized way in order for the tool to easily understand that variants exist and under what cirumstances they exist. But sure, we could easily add a kludge in both winapi_check and any future tools what just ignore any multiple occurance of an already documented function. It will be more errorprone but since this is quite rare perhaps it will not matter so much. Anyway, I don't really very much, so just say how want it: 1. Some way similar to mine (easily parsable structure) 2. Just kludge over this rare case (ignore multiple) 3. Some other way.

1 0

Re: VerQueryValue[A|W]
by James Hatheway Feb. 15, 2001

Feb. 15, 2001

> > To convert an ASCII string to Unicode, you can use the > > function HEAP_strdupAtoW, as in: > Wrong ;-) Yeah, I know, Huw already set me straight on that. ^_^ > HEAP_str* is deprecated (the header file says so). > Use MultiByteToWideChar() or WideCharToMultiByte() instead. I'll admit I wrote the email when my brain wasn't quite working (by def'n anytime after 1am), thought to myself "what is that API again?", did a quick search in WINE, said to myself "oh HEAP_strdupAtoW" sent a quick email and went to bed. :) That teaches me to send email without thinking. But that gets me to my point. HEAP_strdupAtoW is used in this capacity 78 times in the WINE source tree (WtoA another 182 times). We should probably change it sometime, since a lot of people who are writing new code are sure to use the current code base as an example of "how to do things". Out of curiosity, why are we killing these macros? They seem quite convenient. If it is because they aren't in standard windows headers, can't we put them somewhere in include/wine? -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer"

1 0

Re: New EnumPrinterDataEx
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Ian Pilcher <pilcher(a)concentric.net> writes: > In theory, yes. But what about the case of a mistake on my part (or > the part of the person who implemented the underlying call)? We all > do everything possible to produce error-free code, but mistakes *do* > happen. IMHO the likelihood that your macros are going to introduce new bugs is larger than the likelihood that you are ever going to catch a legitimate failure from HeapFree(). Not to mention that there are already WARNs in the heap code that will catch the problem first, so your messages are redundant. Checking for errors is good if you actually handle failures; but if you don't do anything it just obscures the code for no good reason. -- Alexandre Julliard julliard(a)winehq.com

2 1