# Re: SANEI_THREAD proposal

Milon Firikis (milonf@ariadne-t.gr)
Mon, 03 Aug 1998 00:38:37 +0300

- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Yuri Dario: "Re: SANEI_THREAD proposal"
- Previous message: Hugo van der Kooij: "Re: segfault with Microtek Scanmaker 330"
- Maybe in reply to: Yuri Dario: "SANEI_THREAD proposal"
- Next in thread: Yuri Dario: "Re: SANEI_THREAD proposal"

Yuri Dario wrote:
>
> Hi,
>
> 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.
>
> 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 also added reader_fds to Umax_Scanner structure, so I don't need to create another data structure, as I wrote in
> the past.
>
> If you find that changes useful, I will add them also to Mustek,Tamarack, SnapScan, Coolscan backends. Without that
> changes, those backends wont work under OS/2.
>
> I have tested the code on an Umax Astra 610S, connected to my (old!) Adaptec 1542CF.
>
> Bye,
>
> Yuri Dario
>
> /*
> * member of TeamOS/2 - Italy
> */
>

I definitely agree that SANE should implement its own threading
functions.

I consider a bloat the fork staff and a bad thing to do from a backend.
I believe backends should be scanner specific and do not intermix user
interaction or call any OS functions. I actually believe that backends
shouldn't be allowed to issue simple printf 's.

Well, they don't. We have the DBG macro instead which is part of the of
SANE API. If a backend does not do printf why should issue a fork()
which is far more OS specific? I believe that the addition of threading
to the SANE API is a good thing generally speaking.

However I can't have an opinion to this specific proposal since I am not
familiar with threads (Unix threads I mean, p or linux). I took a look
to the proposed patch and it looked good, meaning it shouldn't break
anything. The problem is that I saw some system specific parameters in
the sanei_thread_begin. That's OK with me as long as it leaves room for
a UNIX thread implementation. The problem is that I do not know about
threads and I cannot judge that. What I mean is:

1) Are these parameters meaningfull/usefull for a UNIX threading
implementation.
2) Does the UNIX threading implementation needs more/ others parameters?
if yes, then they should be listed in the parameters list also.

The other thing with the close stuff is more complicated. I thing it
deserves extra discussion.

Milon Firikis

PS

Please note that I do not consider the fork a bad thing under the SANE
API specified threading function. I believe fork is bad if it is stray
issued at a backend body.

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

- Next message: Yuri Dario: "Re: SANEI_THREAD proposal"
- Previous message: Hugo van der Kooij: "Re: segfault with Microtek Scanmaker 330"
- Maybe in reply to: Yuri Dario: "SANEI_THREAD proposal"
- Next in thread: Yuri Dario: "Re: SANEI_THREAD proposal"