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