Mike Hearn <[EMAIL PROTECTED]> writes:
> I quite liked Michaels idea of the RT signals. Is there some reason we
> can't use them?
Portability, plus we don't really want queued behavior anyway.
--
Alexandre Julliard
[EMAIL PROTECTED]
On Sun, Nov 07, 2004 at 10:14:40PM -0800, Dan Kegel wrote:
> Mike Hearn wrote:
> > I quite liked Michaels idea of the RT signals. Is there some reason we
> > can't use them?
>
> I didn't see Michael's proposal. Can you point to it?
>
> Now, I don't pretend to understand the issues here, but read
Mike Hearn wrote:
> I quite liked Michaels idea of the RT signals. Is there some reason we
> can't use them?
I didn't see Michael's proposal. Can you point to it?
Now, I don't pretend to understand the issues here, but reading your patch,
http://www.winehq.org/hypermail/wine-patches/2004/11/att-00
On Sun, 07 Nov 2004 12:10:15 +0200, Jukka Heinonen wrote:
> I was myself thinking about using a single signal
> whose handler just pulls asynchronous requests from
> wineserver as an implementation of the multiplexing system.
> Locking issues could be fixed using worker threads,
> signal safe crit
Alexandre Julliard:
> It would certainly be nice if we could convince dosvm to stop using
> SIGUSR2, there are lots of other things that could make better use of
> it. I don't really have a good solution to offer though (except maybe
> getting rid of dosvm altogether ;-)
Well, I'm not going to co
Jukka Heinonen wrote:
Yep. If using Linux 2.6 kernel and recent pthread library,
threads share the same pid and they must be signalled using
tkill and not kill.
Yes, you're right. I already wondered why dosvm worked before, it was
because I used a 2.4 kernel.
The only place which knows how to
cor
Jukka Heinonen <[EMAIL PROTECTED]> writes:
> Now, I have tried this approach and it seems to work. I have
> some prototype implementation lying around but I was thinking
> about doing something more complicated at the time,
> like using SIGUSR2 handler for doing Win32 remote operations
> discussed
Markus Amsler wrote:
> There's a fundamental bug in winedos/dosvm. c[1]. SIGUSR2 is sent to the
> current process, but it should be sent to the dosvm thread. This causes
> various ugly bugs.
> I found no way signaling a unix thread, without modifing the wineserver.
> I have implemented a thread_
On Thu, Oct 28, 2004 at 11:54:14PM +0200, Markus Amsler wrote:
> I found no way signaling a unix thread, without modifing the wineserver.
> I have implemented a thread_kill command in the wineserver, this solves
> my problem, but i'm quite sure it won't get applied.
>
> I'm really not a wineserv
Hi,
There's a fundamental bug in winedos/dosvm. c[1]. SIGUSR2 is sent to the
current process, but it should be sent to the dosvm thread. This causes
various ugly bugs.
I found no way signaling a unix thread, without modifing the wineserver.
I have implemented a thread_kill command in the wineser
10 matches
Mail list logo
