- Wine-Devel - list.winehq.org

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

Feb. 25, 2001

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 Feb. 25, 2001

Feb. 25, 2001

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 Feb. 25, 2001

Feb. 25, 2001

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 Feb. 25, 2001

Feb. 25, 2001

"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 Feb. 25, 2001

Feb. 25, 2001

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

Printer setup dialog enhancement
by Duane Clark Feb. 24, 2001

Feb. 24, 2001

Howdy, Since the landscape/portrait icons were added to the printer setup dialog a couple weeks ago, here is a minor patch so that the landscape/portrait radio buttons cause an immediate change of the icon. Duane Index: dlls/commdlg/printdlg.c =================================================================== RCS file: /home/wine/wine/dlls/commdlg/printdlg.c,v retrieving revision 1.37 diff -u -r1.37 printdlg.c --- dlls/commdlg/printdlg.c 2001/02/12 19:42:08 1.37 +++ dlls/commdlg/printdlg.c 2001/02/24 19:52:37 @@ -940,12 +940,20 @@ case rad1: /* Paperorientation */ if (lppd->Flags & PD_PRINTSETUP) + { lpdm->u1.s1.dmOrientation = DMORIENT_PORTRAIT; + SendDlgItemMessageA(hDlg, ico1, STM_SETIMAGE, (WPARAM) IMAGE_ICON, + (LPARAM)(PrintStructures->hPortraitIcon)); + } break; case rad2: /* Paperorientation */ if (lppd->Flags & PD_PRINTSETUP) + { lpdm->u1.s1.dmOrientation = DMORIENT_LANDSCAPE; + SendDlgItemMessageA(hDlg, ico1, STM_SETIMAGE, (WPARAM) IMAGE_ICON, + (LPARAM)(PrintStructures->hLandscapeIcon)); + } break; case cmb1:

1 0

SHLocalAlloc
by J.Brown (Ender/Amigo) Feb. 24, 2001

Feb. 24, 2001

I've been trying to get the Windows ME version of internet explorer/explorer to load successfully under Wine.. However, it runs into an unimplemented SHLocalAlloc function in shell32. This appears to be an undocumented function, or I'm looking in the wrong place... has anyone got a patch or API specs on it? Regards, Ender _________________________ ______________________________ | James 'Ender' Brown | "Where are we going, and why | | http://www.enderboi.com | am I in this handbasket?!?" | +-------------------------+------------------------------+

2 1

huge library renaming ?
by Andreas Mohr Feb. 24, 2001

Feb. 24, 2001

Hello all, one thing that occurred to me: Shouldn't we rename *all* Wine libraries to libwineXXX ? AFAIR there have been several naming conflicts with other projects (libole, ...), and people who need to remove a previous Wine install from their system manually have a rather hard time... Any reason for not doing this ? I can't think of any... If this is a good thing, then we should do this NOW, not when it's too late. The current drawbacks are just too much IMHO. Andreas Mohr

6 7

Re: ./dlls/libntdll.so: undefined reference to `PTHREAD_init_done'
by Alexandre Julliard Feb. 23, 2001

Feb. 23, 2001

Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> writes: > I'm leaving for holidays very soon and have to proof-read some 60 exams > before that, so I won't be able to track this down, but perhaps one of > could fix the build failure seen on FreeBSD 4.2? > > Perhaps just some incomplete #ifdef ... #endif sequence? Yep, here's a fix: Index: scheduler/pthread.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/pthread.c,v retrieving revision 1.11 diff -u -r1.11 pthread.c --- scheduler/pthread.c 2001/02/23 01:37:05 1.11 +++ scheduler/pthread.c 2001/02/23 22:27:07 @@ -18,6 +18,13 @@ #include "winbase.h" #include "thread.h" +static int init_done; + +void PTHREAD_init_done(void) +{ + init_done = 1; +} + /* Currently this probably works only for glibc2, * which checks for the presence of double-underscore-prepended * pthread primitives, and use them if available. @@ -86,13 +93,6 @@ #define MAX_KEYS 16 /* libc6 doesn't use that many, but... */ #define P_OUTPUT(stuff) write(2,stuff,strlen(stuff)) - -static int init_done; - -void PTHREAD_init_done(void) -{ - init_done = 1; -} void __pthread_initialize(void) { -- Alexandre Julliard julliard(a)winehq.com

2 1

./dlls/libntdll.so: undefined reference to `PTHREAD_init_done'
by Gerald Pfeifer Feb. 23, 2001

Feb. 23, 2001

I'm leaving for holidays very soon and have to proof-read some 60 exams before that, so I won't be able to track this down, but perhaps one of could fix the build failure seen on FreeBSD 4.2? Perhaps just some incomplete #ifdef ... #endif sequence? : rm -f libwine_unicode.so && ln -s unicode/libwine_unicode.so libwine_unicode.so rm -f libwine_uuid.a && ln -s ole/libwine_uuid.a libwine_uuid.a gmake[1]: Entering directory `/.amd_mnt/vexpert/files8/test/wine/miscemu' LD_LIBRARY_PATH="../unicode:$LD_LIBRARY_PATH" ../tools/winebuild/winebuild -fPIC -L../dlls -o wine.spec.c -spec wine.spec /usr/bin/gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o wine.spec.o wine.spec.c /usr/bin/gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o main.o main.c ld -r wine.spec.o main.o -o miscemu.o gmake[1]: Leaving directory `/.amd_mnt/vexpert/files8/test/wine/miscemu' /usr/bin/gcc -o wine miscemu/miscemu.o -L./dlls -lntdll -L./library -lwine -L./unicode -lwine_unicode -lncurses -lxpg4 -lm -lutil ./dlls/libntdll.so: undefined reference to `PTHREAD_init_done' gmake: *** [wine] Error 1 Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

1 0