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
Alexandre Julliard wrote:
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
"Robert O'Callahan" [EMAIL PROTECTED] writes:
So your concern is simply that if it's too simple to lock the mutex, then
you have an unacceptably high probability of a runaway process
accidentally locking the mutex, whereas you regard the probability of the
process accidentally calling
Ove Kaaven wrote:
On Sat, 24 Feb 2001, Robert O'Callahan wrote:
Ove Kaaven wrote:
On Thu, 22 Feb 2001, Robert O'Callahan wrote:
Then on some other thread in the same address space
that serves wineserver requests:
There's no such thread, and will never be such a thread
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
Alexandre Julliard wrote:
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
"Robert O'Callahan" [EMAIL PROTECTED] 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
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
On Thu, 22 Feb 2001, Robert O'Callahan wrote:
Then on some other thread in the same address space
that serves wineserver requests:
There's no such thread, and will never be such a thread (having the
wineserver calling into client threads is an inherently unstable design).
On Sat, 24 Feb 2001, Robert O'Callahan wrote:
Ove Kaaven wrote:
On Thu, 22 Feb 2001, Robert O'Callahan wrote:
Then on some other thread in the same address space
that serves wineserver requests:
There's no such thread, and will never be such a thread (having the
wineserver
Ove Kaaven wrote:
On Thu, 22 Feb 2001, Robert O'Callahan wrote:
Then on some other thread in the same address space
that serves wineserver requests:
There's no such thread, and will never be such a thread (having the
wineserver calling into client threads is an inherently unstable
Ove Kaaven wrote:
On Sat, 24 Feb 2001, Robert O'Callahan wrote:
Ove Kaaven wrote:
On Thu, 22 Feb 2001, Robert O'Callahan wrote:
Then on some other thread in the same address space
that serves wineserver requests:
There's no such thread, and will never be such a thread (having
Ove,
On Sat, Feb 24, 2001 at 12:06:07PM +0100, Ove Kaaven wrote:
There's no such thread, and will never be such a thread (having the
wineserver calling into client threads is an inherently unstable design).
I think I've read this before, when the topic was FindWindow. IIRC that
thread never
13 matches
Mail list logo
