>My point exactly (i.e. 3 params) --- if the original code used fork(),
> what params would you give to sanei_thread_begin()?
they are reader function address, thread stack size (but could be moved inside API) and a pointer to scanner data
structure.
>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?
that's the problem: I can't use a new semaphore, I need to inherit the previous one.
>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.
Under OS/2, the three initial lettes are used to identify the type of API: Dos stands for Disk Operating System, but it not
related to MS-DOS. Never seen a semaphore under MS-DOS.
>(Of course, if this were the catalyst to bring about an elegant
> improvement in the structure of backends, that would be another story.)
maybe.
>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.
but this needs to have two different coding for threaded systems and non threaded system: using a pipe is available on
both.
Now I'm replacing fork() with my API, otherwise backends doesn't work. So I can have a stable SANE port under OS/2.
When the threaded API will be approved by SANE team, the code could be changed easily.
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