kopia lustrzana https://gitlab.com/sane-project/website
148 wiersze
5.3 KiB
HTML
148 wiersze
5.3 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
|
|
"http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>sane-devel: Re: fork or pthread for async I/O?</TITLE>
|
|
<META NAME="Author" CONTENT="Wolfgang Rapp (wolfgang@rapp-informatik.de)">
|
|
<META NAME="Subject" CONTENT="Re: fork or pthread for async I/O?">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
|
<H1>Re: fork or pthread for async I/O?</H1>
|
|
<!-- received="Thu Feb 3 13:09:55 2000" -->
|
|
<!-- isoreceived="20000203210955" -->
|
|
<!-- sent="Fri, 04 Feb 2000 00:20:21 +0100" -->
|
|
<!-- isosent="20000203232021" -->
|
|
<!-- name="Wolfgang Rapp" -->
|
|
<!-- email="wolfgang@rapp-informatik.de" -->
|
|
<!-- subject="Re: fork or pthread for async I/O?" -->
|
|
<!-- id="389A0D35.5852B883@rapp-informatik.de" -->
|
|
<!-- inreplyto="3899CC41.DE769C16@satzbau-gmbh.de" -->
|
|
<STRONG>From:</STRONG> Wolfgang Rapp (<A HREF="mailto:wolfgang@rapp-informatik.de?Subject=Re:%20fork%20or%20pthread%20for%20async%20I/O?&In-Reply-To=<389A0D35.5852B883@rapp-informatik.de>"><EM>wolfgang@rapp-informatik.de</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Thu Feb 03 2000 - 15:20:21 PST
|
|
<P>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0028.html">Bill Wohler: "SG_BIG_BUFF setting in Problems incorrect"</A>
|
|
<UL>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0026.html">Bill Wohler: "Re: new snapshot?"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0024.html">abel deuring: "Re: fork or pthread for async I/O?"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0036.html">abel deuring: "Re: fork or pthread for async I/O?"</A>
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0025.html">Wolfgang Rapp: "Re: fork or pthread for async I/O?"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0036.html">abel deuring: "Re: fork or pthread for async I/O?"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#27">[ date ]</A>
|
|
<A HREF="index.html#27">[ thread ]</A>
|
|
<A HREF="subject.html#27">[ subject ]</A>
|
|
<A HREF="author.html#27">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
abel deuring wrote:
|
|
<BR>
|
|
<P><EM>>
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> I agree, that the small time window for sending a "read" command after
|
|
</EM><BR>
|
|
<EM>> finishing the previous read and not having the scan head stop is indeed
|
|
</EM><BR>
|
|
<EM>> the main cause for scan heads stops -
|
|
</EM><BR>
|
|
<P>I think this is exactly the main point and I am able to compare .
|
|
<BR>
|
|
<P>Before I did the Unixware 2 port of sane I wrote a driver for Microtek
|
|
<BR>
|
|
Scanmaker.
|
|
<BR>
|
|
In this solution the whole scanning loop was inside the driver and the
|
|
<BR>
|
|
application
|
|
<BR>
|
|
set up one read command for the whole scan. This driver runs mutch more
|
|
<BR>
|
|
faster
|
|
<BR>
|
|
than the sane solution with minimum head stops. It only stops if the
|
|
<BR>
|
|
application must
|
|
<BR>
|
|
swap the huge allocated memory on the same SCSI controller. Mutch more
|
|
<BR>
|
|
better if the
|
|
<BR>
|
|
swap is on a IDE disk or seperate controller.
|
|
<BR>
|
|
<P>If I recogmized it well , all backends send a lot of times the same
|
|
<BR>
|
|
SCSI-Command block with
|
|
<BR>
|
|
following read system call. Is it right that only the last Command differs
|
|
<BR>
|
|
in most cases?
|
|
<BR>
|
|
So the only solution could be that the backends tell sanei_scsi how
|
|
<BR>
|
|
often a certain
|
|
<BR>
|
|
SCSI-Command should be executed and sanei_scsi decides what to do on the
|
|
<BR>
|
|
different
|
|
<BR>
|
|
platforms and alloc the memory. It's clear that this needs special sane
|
|
<BR>
|
|
drivers for every platform
|
|
<BR>
|
|
if the scan should be as fast as possible but don't prevent using the
|
|
<BR>
|
|
current method if no special
|
|
<BR>
|
|
driver is available In my opinion this is the only way to speed up scans
|
|
<BR>
|
|
and avoid head stops.
|
|
<BR>
|
|
What could happen that we can't cancel a scan so easy because we only may
|
|
<BR>
|
|
interrupt system calls
|
|
<BR>
|
|
by signals. But we can send a SIGALRM to do this.
|
|
<BR>
|
|
<P>Greetings Wolfgang
|
|
<BR>
|
|
<P><P><PRE>
|
|
--
|
|
Source code, list archive, and docs: <A HREF="http://www.mostang.com/sane/">http://www.mostang.com/sane/</A>
|
|
To unsubscribe: echo unsubscribe sane-devel | mail <A HREF="mailto:majordomo@mostang.com?Subject=Re:%20fork%20or%20pthread%20for%20async%20I/O?&In-Reply-To=<389A0D35.5852B883@rapp-informatik.de>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0028.html">Bill Wohler: "SG_BIG_BUFF setting in Problems incorrect"</A>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0026.html">Bill Wohler: "Re: new snapshot?"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0024.html">abel deuring: "Re: fork or pthread for async I/O?"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0036.html">abel deuring: "Re: fork or pthread for async I/O?"</A>
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0025.html">Wolfgang Rapp: "Re: fork or pthread for async I/O?"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0036.html">abel deuring: "Re: fork or pthread for async I/O?"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#27">[ date ]</A>
|
|
<A HREF="index.html#27">[ thread ]</A>
|
|
<A HREF="subject.html#27">[ subject ]</A>
|
|
<A HREF="author.html#27">[ author ]</A>
|
|
</UL>
|
|
<!-- trailer="footer" -->
|
|
<HR NOSHADE>
|
|
<P>
|
|
<SMALL>
|
|
<EM>
|
|
This archive was generated by <A HREF="http://www.hypermail.org/">hypermail 2b29</A>
|
|
: <EM>Thu Feb 03 2000 - 13:11:27 PST</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|