kopia lustrzana https://gitlab.com/sane-project/website
103 wiersze
5.1 KiB
HTML
103 wiersze
5.1 KiB
HTML
<!-- received="Tue Aug 4 22:39:17 1998 PDT" -->
|
|
<!-- sent="Wed, 5 Aug 1998 01:38:20 -0400 (EDT)" -->
|
|
<!-- name="Matto Marjanovic" -->
|
|
<!-- email="maddog@mir.com" -->
|
|
<!-- subject="Re: SANEI_THREAD proposal" -->
|
|
<!-- id="m0z3wHE-000J3sC@yoo-hoo.ai.mit.edu" -->
|
|
<!-- inreplyto="SANEI_THREAD proposal" -->
|
|
<title>sane-devel: Re: SANEI_THREAD proposal</title>
|
|
<h1>Re: SANEI_THREAD proposal</h1>
|
|
<b>Matto Marjanovic</b> (<a href="mailto:maddog@mir.com"><i>maddog@mir.com</i></a>)<br>
|
|
<i>Wed, 5 Aug 1998 01:38:20 -0400 (EDT)</i>
|
|
<p>
|
|
<ul>
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#8">[ date ]</a><a href="index.html#8">[ thread ]</a><a href="subject.html#8">[ subject ]</a><a href="author.html#8">[ author ]</a>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0009.html">Matto Marjanovic: "Re: SANE release 0.74 available"</a>
|
|
<li> <b>Previous message:</b> <a href="0007.html">Rogier Wolff: "Re: segfault with Microtek Scanmaker 330"</a>
|
|
<li> <b>Maybe in reply to:</b> <a href="0000.html">Yuri Dario: "SANEI_THREAD proposal"</a>
|
|
<!-- nextthread="start" -->
|
|
<li> <b>Next in thread:</b> <a href="0016.html">Yuri Dario: "Re: SANEI_THREAD proposal"</a>
|
|
<!-- reply="end" -->
|
|
</ul>
|
|
<!-- body="start" -->
|
|
<i> >From: "Yuri Dario" <<a href="mailto:mc6530@mclink.it">mc6530@mclink.it</a>></i><br>
|
|
<i> >Date: Sat, 01 Aug 1998 19:46:30 +0100</i><br>
|
|
<i> ></i><br>
|
|
<i> >I have wrote an initial API for thread support. It consist of 3 functions</i><br>
|
|
<i> ></i><br>
|
|
<i> >extern int sanei_thread_begin( void (*start)(void *arg), </i><br>
|
|
<i> > unsigned stack_size, </i><br>
|
|
<i> > void *arg_list);</i><br>
|
|
<i> >extern int sanei_thread_kill( int pid, int sig);</i><br>
|
|
<i> >extern int sanei_thread_wait( int pid, int *stat_loc, int options);</i><br>
|
|
<i> ></i><br>
|
|
<i> >that should replace fork(), kill() and waitpid(). They have the same</i><br>
|
|
<i> >parameters, except for thread_begin that require a pointer to a</i><br>
|
|
<i> >function, a stack size and a pointer to data.</i><br>
|
|
<p>
|
|
Ooh, this is bad. Good overall idea, but this thing is mixing together<br>
|
|
two fundamentally different constructs; threads and forks are *not*<br>
|
|
interchangeable. Looking at your sanei_thread implementation reveals<br>
|
|
this: you can't drop-in sanei_thread_begin() as a replacement for<br>
|
|
fork() because one takes 3 arguments and other takes none.<br>
|
|
<p>
|
|
First a question: why was it that you couldn't use fork() on OS/2?<br>
|
|
You mentioned earlier that it was a resource hog; could you be more<br>
|
|
specific?<br>
|
|
<p>
|
|
I like the idea of some standard wrappers to handle multitasking stuff<br>
|
|
for SANE backends. However, there should be some wrappers for forks,<br>
|
|
and wrappers for threads, and some #define's for each platform to<br>
|
|
specify if they support one or both (and perhaps neither should be<br>
|
|
necessary for a functional backend). (But, I imagine that fork()<br>
|
|
and its cousins are quite standardized already.)<br>
|
|
<p>
|
|
Forking creates a whole new process (albeit a copy of the original),<br>
|
|
with independent memory space. The only way the new process can<br>
|
|
communicate with the old is via pipes and signals (and perhaps shared<br>
|
|
memory). If a parent process doesn't wait() for its children to<br>
|
|
die, they kind of hang around forever (hoping to someday repore<br>
|
|
back that exit code).<br>
|
|
<p>
|
|
Threads are concurrently running functions (execution stacks) running<br>
|
|
within the same process memory space. So, threads can eliminate a lot<br>
|
|
of overhead by communicating via shared data structures. However, they<br>
|
|
often require semaphores to synchronize things, and some system<br>
|
|
functions are not thread-safe.<br>
|
|
<p>
|
|
A set of wrappers which mixes the two forces a programmer to live in<br>
|
|
the worst of both worlds.<br>
|
|
<p>
|
|
-matt m.<br>
|
|
<p>
|
|
<p>
|
|
PS:<br>
|
|
<p>
|
|
<i> >I have included also the patches to the Umax backend as example. There</i><br>
|
|
<i> >is only one problem: the call to close(fds[1]), must be avoided when</i><br>
|
|
<i> >using threads. I think it could be removed also on other platforms,</i><br>
|
|
<i> >because file handles are closed automatically at process exit. I have</i><br>
|
|
<p>
|
|
Is this because close() is not thread-safe?<br>
|
|
Doesn't each scan opens a new pipe? If so, then pipes would keep<br>
|
|
accumulating until the frontend/backend was killed.<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">majordomo@mostang.com</a>
|
|
</pre>
|
|
<!-- body="end" -->
|
|
<p>
|
|
<ul>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0009.html">Matto Marjanovic: "Re: SANE release 0.74 available"</a>
|
|
<li> <b>Previous message:</b> <a href="0007.html">Rogier Wolff: "Re: segfault with Microtek Scanmaker 330"</a>
|
|
<li> <b>Maybe in reply to:</b> <a href="0000.html">Yuri Dario: "SANEI_THREAD proposal"</a>
|
|
<!-- nextthread="start" -->
|
|
<li> <b>Next in thread:</b> <a href="0016.html">Yuri Dario: "Re: SANEI_THREAD proposal"</a>
|
|
<!-- reply="end" -->
|
|
</ul>
|