On Sat, 15 Jan 2005 03:30:28 +1100, Con Kolivas [EMAIL PROTECTED] wrote:
Ove Kaaven wrote:
The biggest problem is that there is no way to say to the kernel that
one thread is more important than another without permanently renicing
all other threads. A potential kernel solution to the
Jeremy White wrote:
Specifically, there are other areas of interest when you think about
timing and scheduling. First is the Windows very clear cut 'foreground
window' boost. I have no idea how this maps into the Linux
interactivity strategy. They seem to be roughly equivalent, and I
never
Jeremy White wrote:
Photoshop has a thread that runs that samples the mouse position every 5
ms;
if it doesn't get it's samples in the right amount of time, you don't
draw smooth curves. (It may be a timer event callback routine,
or a thread that is woken up by a timer event, I can't recall
fre, 14,.01.2005 kl. 13.06 +1100, skrev Con Kolivas:
Well the scheduler is not going to be rewritten any time soon (trust me,
I've tried :P). Tell me what remaining requirements your threads have
that you are unable to achieve at the moment and I'll see if I can help
with my understanding
Ove Kaaven wrote:
fre, 14,.01.2005 kl. 13.06 +1100, skrev Con Kolivas:
Well the scheduler is not going to be rewritten any time soon (trust me,
I've tried :P). Tell me what remaining requirements your threads have
that you are unable to achieve at the moment and I'll see if I can help
with my
Jeremy White wrote:
Fyi,
I spent a great deal of time this past fall exploring Wine scheduling
issues, and I thought I would post what I learned.
The most critical point is Wine was pretty badly broken;
it simply had a number of flaws in how scheduling was done.
First, the winmm timer, used by a
Well the scheduler is not going to be rewritten any time soon (trust me,
I've tried :P). Tell me what remaining requirements your threads have
that you are unable to achieve at the moment and I'll see if I can help
with my understanding of the priority system as it is, in a generic way
that
[snipping further proof that I don't understand a wide range of issues g]
Fourth, based on your reply to my earlier email, I suspect I do
not understand how time quanta are assigned. In fact, I had come to
some conclusions at one point last fall, that I can no longer
convince myself of (I was
Jeremy White wrote:
Fourth, the Wine server had an issue with the way it managed
it request queues. To be honest, I don't understand this
bug or the fix; all I know is that Mike McCormack figured
this one out and posted a magic fix. This was, I believe,
the primary reason that the wineserver
ons, 12,.01.2005 kl. 12.01 -0600, skrev Jeremy White:
Second, we did not synchronize Wine message times with X11
message times properly. Fixing that resolved some issues
with Photoshop (and given that Ove reworked that patch into
WineX the same day I submitted it, I'd guess it fixed some
On Wed, 12 Jan 2005 12:01:39 -0600, Jeremy White [EMAIL PROTECTED] wrote:
Fyi,
I spent a great deal of time this past fall exploring Wine scheduling
issues, and I thought I would post what I learned.
WoW, thanks for this deeper explanation of your findings. This
modifications will be on
Shachar Shemesh wrote:
From what I understood from him, this had a lot to do with the epoll
change I investigated some time back. I'll let Mike say whether that is so.
There's a bug in the overlapped I/O code in file.c that means a normal
file fd is added to the select() array and never
I wouldn't trust it. An app just misbehaving can trash important parts
of your filesystem. Suid root is just a bad idea, windows being linux
aware or not. Just for mild amusement I think someone being funky got a
windows virus to work under wine if I recall correctly.
Sure. Don't have to be
Mike Hearn wrote:
I wouldn't trust it. An app just misbehaving can trash important
parts of your filesystem. Suid root is just a bad idea, windows being
linux aware or not. Just for mild amusement I think someone being
funky got a windows virus to work under wine if I recall correctly.
Anyway,
Mike Hearn wrote:
I wouldn't trust it. An app just misbehaving can trash important parts
of your filesystem. Suid root is just a bad idea, windows being linux
aware or not. Just for mild amusement I think someone being funky got
a windows virus to work under wine if I recall correctly.
Sure.
Robert Shearman wrote:
Mike Hearn wrote:
I wouldn't trust it. An app just misbehaving can trash important
parts of your filesystem. Suid root is just a bad idea, windows being
linux aware or not. Just for mild amusement I think someone being
funky got a windows virus to work under wine if I
Mike Hearn wrote:
Other solution is just to detect this and ask the user to rerun Wine
as root. I don't think that'd be a big deal.
But then that brings up the issue of users not being able to run wine
merely because they don't have root access, i.e. users on a Linux system
in a business
tir, 31.08.2004 kl. 05.23 skrev [EMAIL PROTECTED]:
On Mon, Aug 30, 2004 at 08:52:04AM +0200, Ove Kaaven wrote:
It's not. Linux only allows non-root processes to reduce its priority,
not increase it, even for non-real-time priorities. Windows, however,
allows it for non-real-time priorities.
2) After you've reduced a thread or process's priority, it's not
possible to elevate it to the original level again (without being root),
so if a thread is set to low priority temporarily, it won't be possible
to restore it to normal priority under Linux. Under Windows it's of
course possible.
On Tue, Aug 31, 2004 at 10:54:46AM +0100, Mike Hearn wrote:
Hmm, so I suppose the idea of getting all wine processes nice 19 and
then doing something internally to manage win's prios when it gets the
CPU is out of the question, right?
It's an issue of performance vs. performance -- performance
Other solution is just to detect this and ask the user to rerun Wine as
root. I don't think that'd be a big deal.
But then that brings up the issue of users not being able to run wine
merely because they don't have root access, i.e. users on a Linux system
in a business environment, or remote
Hopefully, the below information will prove useful regarding this
discussion:
I have an app (United Devices), a distributed computing type program that is
reliant upon threading priorities and remote operation processes. Under
Windows98 - me, the process tree looks as such:
kernel32 Pri class
On Mon, Aug 30, 2004 at 08:52:04AM +0200, Ove Kaaven wrote:
man, 30.08.2004 kl. 02.50 skrev [EMAIL PROTECTED]:
Only root can do this under Linux.
Maybe I sound naive, but would it be possible to get the highest
priority supported by the user (root or otherwise) without going to
root;
søn, 29.08.2004 kl. 04.13 skrev Michael Chang:
I argued with myself about the logic in this for ages. The best I could
come up with is - I don't know :| I'd need to know about windows
scheduling (which I don't)
Obviously, if Win apps have been written to expect this, there's
Ove Kaaven wrote:
søn, 29.08.2004 kl. 04.13 skrev Michael Chang:
Also note that Windows allows a Win32 process to boost its own priority
all the way to what they call real time. Only root can do this under
Linux. I'm not sure if you need administrator privileges to do this
under Windows
søn, 29.08.2004 kl. 11.43 skrev Robert Shearman:
Ove Kaaven wrote:
søn, 29.08.2004 kl. 04.13 skrev Michael Chang:
Also note that Windows allows a Win32 process to boost its own priority
all the way to what they call real time. Only root can do this under
Linux. I'm not sure if you
Ove Kaaven wrote:
søn, 29.08.2004 kl. 04.13 skrev Michael Chang:
I argued with myself about the logic in this for ages. The best I could
come up with is - I don't know :| I'd need to know about windows
scheduling (which I don't)
Obviously, if Win apps have been written to expect this, there's
Hi,
On Sun, Aug 29, 2004 at 10:07:18PM +1000, Con Kolivas wrote:
Audio runs as a separate thread outside of wine potentially through who
knows how many layers as a combination of both process and kernel
context so that's already complicating the issue by having a separate
thread. X does
On Sun, Aug 29, 2004 at 09:51:30AM +0200, Ove Kaaven wrote:
s?n, 29.08.2004 kl. 04.13 skrev Michael Chang:
I argued with myself about the logic in this for ages. The best I could
come up with is - I don't know :| I'd need to know about windows
scheduling (which I don't)
Obviously,
Mike Hearn wrote:
Well, apparently we don't use sched_yield, so the problem must
lie somewhere else. Maybe Con can help us out here? Alexandre says he
doesn't know what the issue is either and somebody needs to
investigate. I
guess we do need to concern ourselves over the details :)
On Sat, Aug 28, 2004 at 01:54:19AM +1000, Con Kolivas wrote:
Mike Hearn wrote:
Well, apparently we don't use sched_yield, so the problem must
lie somewhere else. Maybe Con can help us out here? Alexandre says he
Interesting. Probably the most valuable information is that it seems
to work
Well, apparently we don't use sched_yield, so the problem must
lie somewhere else. Maybe Con can help us out here? Alexandre says he
doesn't know what the issue is either and somebody needs to investigate. I
guess we do need to concern ourselves over the details :)
Interesting. Probably the
Forwarded Message
From: Con Kolivas [EMAIL PROTECTED]
To: Mike Hearn [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [ck] Re: Threading issues? [EMAIL PROTECTED]: ck
Digest, Vol 3, Issue 16]
Date: Sat, 21 Aug 2004 10:39:21 +1000
Mailer: Mozilla Thunderbird 0.7.1
33 matches
Mail list logo
