>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.
I have 3 params because a thread needs them. They aren't needed for fork(). When using fork(), my
sanei_thread_begin() simply executes return fork(); so this doesn't change the code for Unix.
>First a question: why was it that you couldn't use fork() on OS/2?
First, fork() doesn't inherit semaphores; this is the main problem, because there is a shared semaphore used to access
low-level scsi drivers. Second, fork() is not as efficient as under Unix, so it should be avoided (using threads or functions
like spawn).
>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
also better than my idea: so we could split code for particular cases.
> of overhead by communicating via shared data structures. However, they
> often require semaphores to synchronize things, and some system
> functions are not thread-safe.
quite all c-library functions are thread safe, because OS/2 compiler have one runtime for single-threaded programs, and
another for multi-threaded ones. System API are also safe. You only need to protect access to shared resources (like
vars or memory).
>A set of wrappers which mixes the two forces a programmer to live in
> the worst of both worlds.
I don't agree with you: actually backends uses a pipe to communicate under Unix, and the same way between OS/2
threads. But we could add some rules for that.
>Is this because close() is not thread-safe?
no, simply because the pipe has two channel: one for read and the other for writing. In my threaded implementation, the
thread is using the write channel to send data to the reader process (which is reading from fds[0]). So I can't close the
handle; under unix the parent process doesn't need the write handle, so it can safely be closed.
>Doesn't each scan opens a new pipe? If so, then pipes would keep
> accumulating until the frontend/backend was killed.
it seems to me that backends call pipe() every time before scanning a page.
Bye,
Yuri Dario
/*
* member of TeamOS/2 - Italy
*/
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com