>From: "Yuri Dario" <mc6530@mclink.it>
>Date: Wed, 05 Aug 1998 15:05:33 +0100
>
>On Wed, 5 Aug 1998 01:38:20 -0400 (EDT), Matto Marjanovic wrote:
>
...
>> 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.
My point exactly (i.e. 3 params) --- if the original code used fork(),
what params would you give to sanei_thread_begin()?
>>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).
Efficiency issues aside, is that semaphore really necessary?
...Ok, after perusing the code, I guess so. And the semaphore, being
"DC_SEM_SHARED" and all, doesn't get shared with a child process? Lame.
Would it be possible for the OS/2 sanei_scsi commands to check if the
pid has changed, and then create a new semaphore in the child?
It seems really backwards to hack all the backends to accommodate the
deficiencies of some DOS-based device driver (e.g. "DosCreateEventSem()"),
since, if I wanted to be stuck in the DOS world, I wouldn't be using Unix.
(Of course, if this were the catalyst to bring about an elegant
improvement in the structure of backends, that would be another story.)
>>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
...
>>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.
If I wrote a backend to use threads under Unix, I wouldn't use pipes at
all. I would just write directly into some buffer, since all the threads
in a process share the same memory space. That's the major advantage of
threads.
-matt m.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com