# Re: SANEI_THREAD proposal

Matto Marjanovic (maddog@mir.com)
Wed, 5 Aug 1998 01:38:20 -0400 (EDT)

- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Matto Marjanovic: "Re: SANE release 0.74 available"
- Previous message: Rogier Wolff: "Re: segfault with Microtek Scanmaker 330"
- Maybe in reply to: Yuri Dario: "SANEI_THREAD proposal"
- Next in thread: Yuri Dario: "Re: SANEI_THREAD proposal"

>From: "Yuri Dario" <mc6530@mclink.it>
>Date: Sat, 01 Aug 1998 19:46:30 +0100
>
>I have wrote an initial API for thread support. It consist of 3 functions
>
>extern int sanei_thread_begin( void (*start)(void *arg),
> unsigned stack_size,
> void *arg_list);
>extern int sanei_thread_kill( int pid, int sig);
>extern int sanei_thread_wait( int pid, int *stat_loc, int options);
>
>that should replace fork(), kill() and waitpid(). They have the same
>parameters, except for thread_begin that require a pointer to a
>function, a stack size and a pointer to data.

Ooh, this is bad. Good overall idea, but this thing is mixing together
two fundamentally different constructs; threads and forks are *not*
interchangeable. Looking at your sanei_thread implementation reveals
this: you can't drop-in sanei_thread_begin() as a replacement for
fork() because one takes 3 arguments and other takes none.

First a question: why was it that you couldn't use fork() on OS/2?
You mentioned earlier that it was a resource hog; could you be more
specific?

I like the idea of some standard wrappers to handle multitasking stuff
for SANE backends. However, there should be some wrappers for forks,
and wrappers for threads, and some #define's for each platform to
specify if they support one or both (and perhaps neither should be
necessary for a functional backend). (But, I imagine that fork()
and its cousins are quite standardized already.)

Forking creates a whole new process (albeit a copy of the original),
with independent memory space. The only way the new process can
communicate with the old is via pipes and signals (and perhaps shared
memory). If a parent process doesn't wait() for its children to
die, they kind of hang around forever (hoping to someday repore
back that exit code).

Threads are concurrently running functions (execution stacks) running
within the same process memory space. So, threads can eliminate a lot
of overhead by communicating via shared data structures. However, they
often require semaphores to synchronize things, and some system
functions are not thread-safe.

A set of wrappers which mixes the two forces a programmer to live in
the worst of both worlds.

-matt m.

PS:

>I have included also the patches to the Umax backend as example. There
>is only one problem: the call to close(fds[1]), must be avoided when
>using threads. I think it could be removed also on other platforms,
>because file handles are closed automatically at process exit. I have

Is this because close() is not thread-safe?
Doesn't each scan opens a new pipe? If so, then pipes would keep
accumulating until the frontend/backend was killed.

    --
    Source code, list archive, and docs: http://www.mostang.com/sane/
    To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

- Next message: Matto Marjanovic: "Re: SANE release 0.74 available"
- Previous message: Rogier Wolff: "Re: segfault with Microtek Scanmaker 330"
- Maybe in reply to: Yuri Dario: "SANEI_THREAD proposal"
- Next in thread: Yuri Dario: "Re: SANEI_THREAD proposal"