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 E
> 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 ar
"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 acc
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 abs
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 pe
"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 xsan
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,
> 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 Win
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 ye
"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 "
sha Mal
--- On Sun 10/14, Julien BLACHE < [EMAIL PROTECTED] > wrote:
From: Julien 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
co
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
12 matches
Mail list logo
