kopia lustrzana https://gitlab.com/sane-project/website
162 wiersze
6.3 KiB
HTML
162 wiersze
6.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="abel deuring (a.deuring@satzbau-gmbh.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 10:53:37 2000" -->
|
|
<!-- isoreceived="20000203185337" -->
|
|
<!-- sent="Thu, 03 Feb 2000 19:43:13 +0100" -->
|
|
<!-- isosent="20000203184313" -->
|
|
<!-- name="abel deuring" -->
|
|
<!-- email="a.deuring@satzbau-gmbh.de" -->
|
|
<!-- subject="Re: fork or pthread for async I/O?" -->
|
|
<!-- id="3899CC41.DE769C16@satzbau-gmbh.de" -->
|
|
<!-- inreplyto="38990253.1593F40@interlog.com" -->
|
|
<STRONG>From:</STRONG> abel deuring (<A HREF="mailto:a.deuring@satzbau-gmbh.de?Subject=Re:%20fork%20or%20pthread%20for%20async%20I/O?&In-Reply-To=<3899CC41.DE769C16@satzbau-gmbh.de>"><EM>a.deuring@satzbau-gmbh.de</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Thu Feb 03 2000 - 10:43:13 PST
|
|
<P>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0025.html">Wolfgang Rapp: "Re: fork or pthread for async I/O?"</A>
|
|
<UL>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0023.html">John Vickers: "Re: List Test #2"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0019.html">Douglas Gilbert: "Re: fork or pthread for async I/O?"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0027.html">Wolfgang Rapp: "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="0027.html">Wolfgang Rapp: "Re: fork or pthread for async I/O?"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#24">[ date ]</A>
|
|
<A HREF="index.html#24">[ thread ]</A>
|
|
<A HREF="subject.html#24">[ subject ]</A>
|
|
<A HREF="author.html#24">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
Douglas Gilbert wrote:
|
|
<BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Most scsi scanners do not support disconnect or tagged queuing
|
|
</EM><BR>
|
|
<EM>> so you are not going to get much benefit from async io. Abel
|
|
</EM><BR>
|
|
<EM>> Deuring has done some work in this area and did get some
|
|
</EM><BR>
|
|
<EM>> timing improvements on Linux. I think scsi commands were
|
|
</EM><BR>
|
|
<EM>> probably queued up at the HBA and thus got out to the
|
|
</EM><BR>
|
|
<EM>> scanner quicker after it finished the previous command
|
|
</EM><BR>
|
|
<EM>> (compared with having to go up through the scsi layers,
|
|
</EM><BR>
|
|
<EM>> out to the app and back down again). Abel used non blocking
|
|
</EM><BR>
|
|
<EM>> techniques rather than POSIX threads, I think. [I have used
|
|
</EM><BR>
|
|
<EM>> POSIX threads to do async IO on high end disks with good
|
|
</EM><BR>
|
|
<EM>> results (compared with the standard dd command).]
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> There seems to be a non-linear effect with scanners. You have
|
|
</EM><BR>
|
|
<EM>> a time window to get the next "read" out to the device after
|
|
</EM><BR>
|
|
<EM>> the previous one has finished. If the window is missed the
|
|
</EM><BR>
|
|
<EM>> scan stops, the mechanism backs up a little and recommences.
|
|
</EM><BR>
|
|
<EM>> A small change in the speed the next command gets out to the
|
|
</EM><BR>
|
|
<EM>> scanner can mean the difference between a slow, jerky scan
|
|
</EM><BR>
|
|
<EM>> and one continuous pass.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<P>Douglas,
|
|
<BR>
|
|
<P>I agree, that the small time window for sending a "read" command after
|
|
<BR>
|
|
finishing the previous read and not having the scan head stop is indeed
|
|
<BR>
|
|
the main cause for scan heads stops -- at least for the Sharp JX250. And
|
|
<BR>
|
|
using SG level queueing together with larger buffers avoids nearly all
|
|
<BR>
|
|
scan head stops. That was the main reason for me to modify sanei_scsi.c
|
|
<BR>
|
|
so that the features of the newer version of the Linux SG driver can be
|
|
<BR>
|
|
used.
|
|
<BR>
|
|
<P>But the Sharp backend also forks a reader process. This was one of my
|
|
<BR>
|
|
first attempts to avoid scan head stops, and it was, combined with
|
|
<BR>
|
|
queueing on the level of the sanei_scsi.c layer, also to some extent
|
|
<BR>
|
|
successful. I am not sure, what would happen, if I would throw away the
|
|
<BR>
|
|
reader process and implement queueing inside the main process. With the
|
|
<BR>
|
|
recent versions of the Linux SG driver, scan head stops would probably
|
|
<BR>
|
|
no longer occur, but since command queueing is implemented in
|
|
<BR>
|
|
sanei_scsi.c only for Linux, I kept the reader process.
|
|
<BR>
|
|
<P>I do not know Ingo's reasons to consider to use either fork() or Posix
|
|
<BR>
|
|
threads in his backend. But if scan head stops occur for his scanner,
|
|
<BR>
|
|
using either of these techniques might be reasonable, simply because
|
|
<BR>
|
|
they work not only for Linux.
|
|
<BR>
|
|
<P>Abel
|
|
<BR>
|
|
<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=<3899CC41.DE769C16@satzbau-gmbh.de>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0025.html">Wolfgang Rapp: "Re: fork or pthread for async I/O?"</A>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0023.html">John Vickers: "Re: List Test #2"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0019.html">Douglas Gilbert: "Re: fork or pthread for async I/O?"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0027.html">Wolfgang Rapp: "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="0027.html">Wolfgang Rapp: "Re: fork or pthread for async I/O?"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#24">[ date ]</A>
|
|
<A HREF="index.html#24">[ thread ]</A>
|
|
<A HREF="subject.html#24">[ subject ]</A>
|
|
<A HREF="author.html#24">[ 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 - 10:56:21 PST</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|