Hello,
this bug was closed and archived in 2010.
Then in 2011 this bug was reopened and unarchived without any comments.
I close this bug.
Thank you for spending your time.
If this bug still occurs please feel free to file a new bug.
CU
Jörg
--
pgp Fingerprint: 7D13 3C60 0A10 DBE1 51F8
I know what you propose won't work.
Ok. If solutions A and B don't work this doesn't mean there exists no third
solution. It's not my job to propose a solution anyway, it's the job of a
SANE-programmer. My job is the telling the discrepancy between the wanted and
observed behaviour. You
sasha mal [EMAIL PROTECTED] wrote:
What you are saying is that it costs too much to fix the slowdown and
my solutions are not good because of some reasons I have no idea of.
What part of what you propose is going to induce horrible side
effects for the frontends and it's not portable accross
Renicing saned doesn't renice xsane automatically. Renicing one process
influences only the future children. So your note is irrelevant.
Look at setpriority(...) and/or sched_yield().
Good example for any of the saned copies:
if(number_of_read_bytes==0) sched_yield();
sasha mal [EMAIL PROTECTED] wrote:
Hi,
Renicing saned doesn't renice xsane automatically. Renicing one
process influences only the future children. So your note is
irrelevant.
Because in this case, the frontend, as far as the mustek_pp backend is
concerned, is saned itself and not xsane
If you suppose that my suggestion is not applicable,
it's not a reason to close the bug.
100% slowdown is a bug.
What solutions are applicable and what are not applicable is a different
question.
___
Join Excite! - http://www.excite.com
The most
What you are saying is that it costs too much to fix the slowdown and my
solutions are not good because of some reasons I have no idea of.
This is your explanation for your unwillingness to fix it. Well, I have to
accept
that.
However, having or not having time resourses on your side is
Nobody requires the behaviour to be generalized to other scanner drivers and
other scanner. To claim that something is a bug, it suffices to give one
counterexample of bad behaviour, for one configuration. Here is one. (Well
knowing that MS Windows allowed even a faster scanning, even many
sasha mal [EMAIL PROTECTED] wrote:
Hi,
Nobody requires the behaviour to be generalized to other scanner
drivers and other scanner. To claim that something is a bug, it
suffices to give one counterexample of bad behaviour, for one
configuration. Here is one. (Well knowing that MS Windows
sasha mal [EMAIL PROTECTED] wrote:
Hi,
Probably the idle copy of saned doesn't give away its time slice
It's *NOT* an idle copy. It's actually the saned process you started,
the one which beams back the data to your frontend.
when it has nothing better to do. Well, renicing is not help a
Package: xsane
Version: 0.99+0.991-2
I turned on the local scanner, put some sheet of paper into in, started xsane.
Looked with ps aux on the process list and saw saned there. Then I started
acquring a preview of a A4 sheet of paper. Looking of the list of processes
with top, I noticed two
BLACHE [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Sun, 14 Oct 2007 19:25:26 +0200
Subject: Re: Bug#446643: saned is started twice with the same priority, one
copy gets in the way of another copy
sasha mal[EMAIL PROTECTED] wrote:Hi, I turned on the local
12 matches
Mail list logo
