kopia lustrzana https://gitlab.com/sane-project/website
188 wiersze
6.6 KiB
HTML
188 wiersze
6.6 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="Fri Feb 4 03:56:29 2000" -->
|
|
<!-- isoreceived="20000204115629" -->
|
|
<!-- sent="Fri, 04 Feb 2000 13:06:25 +0100" -->
|
|
<!-- isosent="20000204120625" -->
|
|
<!-- name="abel deuring" -->
|
|
<!-- email="a.deuring@satzbau-gmbh.de" -->
|
|
<!-- subject="Re: fork or pthread for async I/O?" -->
|
|
<!-- id="389AC0C1.9A900DC3@satzbau-gmbh.de" -->
|
|
<!-- inreplyto="389A0D35.5852B883@rapp-informatik.de" -->
|
|
<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=<389AC0C1.9A900DC3@satzbau-gmbh.de>"><EM>a.deuring@satzbau-gmbh.de</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Fri Feb 04 2000 - 04:06:25 PST
|
|
<P>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0037.html">Harald Kirsch: "lunatic listserver"</A>
|
|
<UL>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0035.html">abel deuring: "Re: SG_BIG_BUFF setting in Problems incorrect"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0027.html">Wolfgang Rapp: "Re: fork or pthread for async I/O?"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0025.html">Wolfgang Rapp: "Re: fork or pthread for async I/O?"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#36">[ date ]</A>
|
|
<A HREF="index.html#36">[ thread ]</A>
|
|
<A HREF="subject.html#36">[ subject ]</A>
|
|
<A HREF="author.html#36">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
Wolfgang Rapp wrote:
|
|
<BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> abel deuring wrote:
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<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>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> I think this is exactly the main point and I am able to compare .
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> Before I did the Unixware 2 port of sane I wrote a driver for Microtek
|
|
</EM><BR>
|
|
<EM>> Scanmaker.
|
|
</EM><BR>
|
|
<EM>> In this solution the whole scanning loop was inside the driver and the
|
|
</EM><BR>
|
|
<EM>> application
|
|
</EM><BR>
|
|
<EM>> set up one read command for the whole scan. This driver runs mutch more
|
|
</EM><BR>
|
|
<EM>> faster
|
|
</EM><BR>
|
|
<EM>> than the sane solution with minimum head stops. It only stops if the
|
|
</EM><BR>
|
|
<EM>> application must
|
|
</EM><BR>
|
|
<EM>> swap the huge allocated memory on the same SCSI controller. Mutch more
|
|
</EM><BR>
|
|
<EM>> better if the
|
|
</EM><BR>
|
|
<EM>> swap is on a IDE disk or seperate controller.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> If I recogmized it well , all backends send a lot of times the same
|
|
</EM><BR>
|
|
<EM>> SCSI-Command block with
|
|
</EM><BR>
|
|
<EM>> following read system call. Is it right that only the last Command differs
|
|
</EM><BR>
|
|
<EM>> in most cases?
|
|
</EM><BR>
|
|
<EM>> So the only solution could be that the backends tell sanei_scsi how
|
|
</EM><BR>
|
|
<EM>> often a certain
|
|
</EM><BR>
|
|
<EM>> SCSI-Command should be executed and sanei_scsi decides what to do on the
|
|
</EM><BR>
|
|
<EM>> different
|
|
</EM><BR>
|
|
<EM>> platforms and alloc the memory. It's clear that this needs special sane
|
|
</EM><BR>
|
|
<EM>> drivers for every platform
|
|
</EM><BR>
|
|
<EM>> if the scan should be as fast as possible but don't prevent using the
|
|
</EM><BR>
|
|
<EM>> current method if no special
|
|
</EM><BR>
|
|
<EM>> driver is available In my opinion this is the only way to speed up scans
|
|
</EM><BR>
|
|
<EM>> and avoid head stops.
|
|
</EM><BR>
|
|
<EM>> What could happen that we can't cancel a scan so easy because we only may
|
|
</EM><BR>
|
|
<EM>> interrupt system calls
|
|
</EM><BR>
|
|
<EM>> by signals. But we can send a SIGALRM to do this.
|
|
</EM><BR>
|
|
<P>I think, there already exists a mechanism in sanei_scsi.c, the function
|
|
<BR>
|
|
pair sanei_scsi_req_enter (send a SCSI command to the scanner) /
|
|
<BR>
|
|
sanei_scsi_req_wait (wait for the results of the command).
|
|
<BR>
|
|
Unfortunately, they are at present only for Linux implemented in "real"
|
|
<BR>
|
|
way; for the other OS, sanei_scsi_req_enter simply calls sanei_scsi_cmd,
|
|
<BR>
|
|
and sanei_scsi_req_wait is empty.
|
|
<BR>
|
|
<P>But there are some scanners, for which the queueing does not seem to
|
|
<BR>
|
|
help: I pplayed a little bit with an old Mustek scanner (sorry, I don't
|
|
<BR>
|
|
know the exact type; it was sold in Germany under the brand name
|
|
<BR>
|
|
"Network", and the inquiry command did not tell me anything I could
|
|
<BR>
|
|
recognise as a model specification...) The Mustek backend already
|
|
<BR>
|
|
supports queueing, therefore I hoped that my patches to the Linux
|
|
<BR>
|
|
queueing might help to avoid some scan head stops, but I had no luck. I
|
|
<BR>
|
|
guess that the scanners's firmware is a little bit stupid, and stops
|
|
<BR>
|
|
after every "read scan data" command. With such a scanner, the only way
|
|
<BR>
|
|
to improve the scan speed is to use large buffers.
|
|
<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=<389AC0C1.9A900DC3@satzbau-gmbh.de>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0037.html">Harald Kirsch: "lunatic listserver"</A>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0035.html">abel deuring: "Re: SG_BIG_BUFF setting in Problems incorrect"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0027.html">Wolfgang Rapp: "Re: fork or pthread for async I/O?"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0025.html">Wolfgang Rapp: "Re: fork or pthread for async I/O?"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#36">[ date ]</A>
|
|
<A HREF="index.html#36">[ thread ]</A>
|
|
<A HREF="subject.html#36">[ subject ]</A>
|
|
<A HREF="author.html#36">[ 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>Fri Feb 04 2000 - 03:56:56 PST</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|