Milon> Note that the objective is to hide all Unix specific
Milon> functions from the backend much like the sanei_scsi_ routines
Milon> do for scsi operations.
You're wrong. Yes, the _API_ must be OS independent but the sample
implementation that we distribute is developed and intended for
POSIX-compatible systems. If we can port that source to other
platforms easily and cleanly, great, but to say that we want to hide
all UNIX/POSIX specific functions is silly.
The issue with fork() is that it's hard (inefficient) to implement on
any system that doesn't have virtual memory. However, threads do not
necessarily solve the problem either. E.g., on systems supporting
user-level threads only (e.g., SunOS, HP-UX up to 10.20, etc.), a
thread may not even help for SANE backends.
Anyhow, if someone modifies the backends to abstract fork() in an
elegant way, I'd be happy to merge in such patches. But if it can't
be done cleanly, you'd be better of creating and maintaining your own
SANE implementation. It's perfectly OK to have multiple SANE
implementations as long as they can interoperate.
--david
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com