- Wine-devel - list.winehq.org

Re: Speeding up wineserver synchronization objects with shared memory
by Alexandre Julliard 26 Feb '01

26 Feb '01

"Robert O'Callahan" <roc+(a)cs.cmu.edu> writes: > Of course it has to be 100% reliable, but since you're dealing with > failing processes it's not 100% clear what 100% reliability is. Anyway, I > think 100% reliability is possible for any plausible definition. For a mutex the basic definition is obviously that you can never have two threads holding the mutex at the same time, and that when it is released some other thread has a chance at grabbing it. This has to be true no matter what the process does, including corrupting memory or crashing. You also need to make sure nothing a process does should be able to crash/hang the wineserver or another process (except if they fight over the same mutex of course), and then there is the small matter of respecting the Win32 semantics... Actually it is the last constraint that is the main problem. You can certainly provide some kind of mutexes using shared memory; but we don't need just 'some kind', we need Win32 mutexes. This means a mutex is identified by a handle that can be manipulated by CloseHandle or DuplicateHandle; it means you need to detect and handle abandoned mutexes; it means you must support WaitForMultipleObjects, including the 'all' case where you cannot grab the mutex unless all objects are signaled; all things that I didn't see in your implementation ;-) -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: undefined symbol: GetPrinterDataA
by gerard patel 26 Feb '01

26 Feb '01

At 08:30 PM 25/02/2001 +0600, you wrote: >I am trying to modify the Wine PostScript driver to use GetPrinterDataA >to read configuration information from the registry. I have added a >line that reads "import winspool.drv" to wineps.spec, and Wine builds >with no errors. When I try to run Wine, however, I get the following >error: > > BUILTIN32_dlopen failed to load .so lib for builtin wineps.dll: > /usr/lib/wine/libwineps.so: undefined symbol: GetPrinterDataA Note the differences between the Makefile for common dialog (where this works) and the Makefile for wineps : commdlg : # Generated automatically from Makefile.in by configure. TOPSRCDIR = ../.. TOPOBJDIR = ../.. SRCDIR = . MODULE = comdlg32 ALTNAMES = commdlg EXTRALIBS = $(LIBUUID) LDDLLFLAGS = -Wl,-Bsymbolic SYMBOLFILE = $(MODULE).tmp.o (...) wineps : # Generated automatically from Makefile.in by configure. TOPSRCDIR = ../.. TOPOBJDIR = ../.. SRCDIR = . MODULE = wineps SOVERSION = 1.0 ALTNAMES = wineps16 IMPORTS = user32 gdi32 kernel32 ntdll C_SRCS = \ (...) I think that the mechanism is not working because dlls separation is not done for wineps ;-) Gerard

1 0

Re: undefined symbol: GetPrinterDataA
by Ian Pilcher 26 Feb '01

26 Feb '01

lawson_whitney(a)juno.com wrote: > > I think maybe you have created a new dependency and need to run make > depend again? If I understand the import mechanism, something > (winebuild?) generates stubs for the functions you import and ties them > in to the import mechanism, so they shouldn't be left hanging for ld.so > to choke on. They should resolve to .spec.o. It looks to me as if the > .spec didin't get rebuilt. > If only it were that simple. I've rebuilt from scratch, with a clean source tree. -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

2 3

Re: various config files for various applications
by Alexandre Julliard 26 Feb '01

26 Feb '01

Martin Pilka <mpilka(a)codeweavers.com> writes: > another way could be have some additional (let's say > ~/.wine/app-config/1database.txt) file which will contain <regular > expression> --> <filename> mappings. that way wine have to open (and > read) only that file, and we're able to do that pretty fast (as i found > out when worked on registry patch). however, it has to evaluate all the > reg. expressions at runtime, but that is linear dependency. > > hmm, i don't know now. first letter or an additional file? This is getting way too complex IMO. I think having everything in the .wine/config file is much more reasonable; most people don't need that many different configurations anyway. What we should do is take advantage of the new config file format to create a deeper configuration hierarchy. So for instance the default x11drv config is under the registry key Wine\Config\x11drv, but we could create subtrees like Wine\Config\AppDefaults\Solitaire\x11drv which would contain the Solitaire-specific config values. This is then very fast to lookup, just try AppDefaults\<current module> and if not found fall back to the current method. I don't think we need regular expressions at all. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: Re: undefined symbol: GetPrinterDataA
by Eric Pouech 26 Feb '01

26 Feb '01

>wineps : > ># Generated automatically from Makefile.in by configure. >TOPSRCDIR = ../.. >TOPOBJDIR = ../.. >SRCDIR = . >MODULE = wineps >SOVERSION = 1.0 >ALTNAMES = wineps16 >IMPORTS = user32 gdi32 kernel32 ntdll in this case, just add winspool.drv to the IMPORT list in the Makefile.in, rerun configure, and it should work. (If Alexandre didn't convert the Makefile.in for dll separation, there should be some good reasons... like using non exported symbols... which would require much more work) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 1

Re: Speeding up wineserver synchronization objects with shared memory
by Alexandre Julliard 26 Feb '01

26 Feb '01

Gavriel State <gav(a)transgaming.com> writes: > Even without that approach though, I don't think that the new failure mode > is really likely to be that big a deal. If process A owns a mutex that process > B wants, they quite likely have some functional interdependance which would be > disrupted as much by any generic hang in process A as by a hang followed by > a failure to release the mutex. Imagine a process that does a SuspendThread() on one of its threads, but makes sure by some kind of internal protocol that the thread is never holding the mutex when it is suspended. This would work just fine under Windows or under the wineserver, but would fail with the shared memory approach. There is simply no point in implementing a mutex that works only 99% of the time, no matter how fast it is. The synchronization objects have to be 100% reliable, performance only comes next; and none of the shared memory approaches I've seen so far are 100% reliable. In fact the original implementation of the kernel objects was based on shared memory and signals. A lot of time was spent trying to make this work right, but it was simply not possible without assuming that all processes will always follow the protocol correctly, which is clearly not something we can assume when running arbitrary Windows code. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver synchronization objects with shared memory
by Michael McCormack 26 Feb '01

26 Feb '01

Two things: 1. How about expiring client's unix file descriptors by having wineserver writing a single non-zero byte[*] to the server-communication socket when another client modifies the fd? The code to validate fds before use could then be reduced from a server call to a single nonwaiting poll on NtCurrentTeb()->reply_fd. 2. How about using pipes to implement critical sections? InitCriticalSection would create a pipe and write one byte, EnterCritical section would do a poll on the pipe, followed by a read of one byte, and leave critical section would write one byte back to the pipe. [*] wineserver would write a zero byte when it wished to restart a client after a server call, and the client would need to check this. Mike -- __________________________________________________________________ mailto:Michael.McCormack(a)alcatel.com.au phone: (+82 11 430 0425)

1 0

Re: Speeding up wineserver synchronization objects with shared memory
by Michael McCormack 26 Feb '01

26 Feb '01

Two things: 1. How about expiring client's unix file descriptors by having wineserver writing a single non-zero byte[*] to the server-communication socket when another client modifies the fd? The code to validate fds before use could then be reduced from a server call to a single nonwaiting poll on NtCurrentTeb()->reply_fd. 2. How about using pipes to implement critical sections? InitCriticalSection would create a pipe and write one byte, EnterCritical section would do a poll on the pipe, followed by a read of one byte, and leave critical section would write one byte back to the pipe. [*] wineserver would write a zero byte when it wished to restart a client after a server call, and the client would need to check this. Mike -- __________________________________________________________________ mailto:Michael.McCormack(a)alcatel.com.au phone: (+612) 9690 5305

1 0

Re: [PATCH] 16 bits print dialog
by Dmitry Timoshkov 25 Feb '01

25 Feb '01

"gerard patel" <gerard.patel(a)asi.fr> wrote: > As it's rather unlikely anyone will craft 16 bits specific resources now, I have > mapped the 32 bits resource into 16 bit ones > I did not test if 16 bits printing still works, but the print dialog box displays again > at least. > There is also a minor fix to cast the return value for the 16 bits hook to 16 bits. > > ChangeLog: > > * dlls/commdlg/printdlg.c > maps 32 bits resource for 16 bits print dialog. Gerard, your patch is fine, but I have one tiny comment: in Win32 hInstance and hModule are the same thing, unlike in Win16. So, instead of GetModuleHandleA("COMDLG32") you can safely use COMMDLG_hInstance32.

1 0

Re: Speeding up wineserver synchronization objects with shared memory
by Robert O'Callahan 25 Feb '01

25 Feb '01

I was just reading WWN and saw this discussion. Here's a wacky idea that might or might not work. The basic idea is to grant ownership of each mutex to one Win32 process at a time. Let any thread grab the mutex quickly if it belongs to the process that owns the mutex. If its process does not own the mutex, then it must communicate with the wineserver and the wineserver must communicate with the owning process to transfer ownership of the mutex from the current owner to the requesting thread. Here's how to implement it. For each Win32 process, for each mutex that's been mapped into it using DuplicateHandle or whatever, allocate a standard shared-memory-based critical section, along with a weOwnIt flag that indicates whether we own the mutex or not. Processes that don't own the mutex leave their critical sections locked. Then implement the operations as follows: AcquireMutex { retry: TryToEnterCriticalSection(); // nonblocking if (failed) { if (!weOwnIt) { wineserver->GiveUsOwnership(); // blocking goto retry; } else { EnterCriticalSection(); // blocking } } } ReleaseMutex { LeaveCriticalSection(); } Then on some other thread in the same address space that serves wineserver requests: WineserverGrantsUsOwnership { weOwnIt = true; LeaveCriticalSection(); } WineserverWantsToTakeAwayOwnership { EnterCriticalSection(); weOwnIt = false; wineserver->WeHaveGivenUpOwnership(); } Because the ownership test in AcquireMutex can race, the server needs to ignore GiveUsOwnership requests for processes that already own the mutex. It seems like this will be efficient (a lot more efficient than a kernel call actually) unless the mutex is pingponging between processes, in which case you'll be eating lots of context switches anyway. In terms of safety, a correctly functioning process will never complete AcquireMutex unless the wineserver has granted it the mutex. A misbehaving process can hold the mutex indefinitely or incorrectly think it has the mutex, but of course that's true under any scheme. When the wineserver terminates a process, it can reassign mutex ownership. (So if a process is asked to give up the mutex but doesn't, the wineserver can time out, kill the process and grant the mutex to someone else). Rob

4 6