[sane-standard] SANE2: Threading
olaf.meeuwissen at avasys.jp
Wed Jan 17 00:46:57 CET 2007
Sorry for the late followup.
"m. allan noah" <anoah at pfeiffer.edu> writes:
> On Thu, 21 Dec 2006, Olaf Meeuwissen wrote:
>> "m. allan noah" <anoah at pfeiffer.edu> writes:
>>> if we determine to keep the threading/forking support, what about the
>>> possibility to 'move' this code up one layer, perhaps into the dll
>>> backend? then we only have to write it once, as opposed to in each
>>> backend. perhaps a layer between the dll and regular backends?
>> Won't that introduce problems when applications link with a backend
>> (other than the dll backend) directly? The SANE standard specifically
>> allows this and even touts it as a "feature".
> when i look at the various sane backend .so files, they have modified
> versions of the function names in the sane api. so any such direct
> linking would require a different compilation of the backend?
Not AFAIU. All backends provide two APIs, one the real SANE API, the
other "shadow" API is for use by the dll backend. The latter just
inserts the backend name after the sane_ bit. For example:
olaf at geek:~$ nm -D -C /usr/lib/sane/libsane-snapscan.so | grep sane_
0000e580 T sane_cancel
0000e550 T sane_close
0000e6b0 T sane_control_option
0000e530 T sane_exit
0000e750 T sane_get_devices
0000e6f0 T sane_get_option_descriptor
0000e680 T sane_get_parameters
0000e5b0 T sane_get_select_fd
0000e780 T sane_init
0000e720 T sane_open
0000e610 T sane_read
0000e5e0 T sane_set_io_mode
00006760 T sane_snapscan_cancel
00007c60 T sane_snapscan_close
0000aac0 T sane_snapscan_control_option
00004a20 T sane_snapscan_exit
000053e0 T sane_snapscan_get_devices
00003d80 T sane_snapscan_get_option_descriptor
00003a40 T sane_snapscan_get_parameters
00003940 T sane_snapscan_get_select_fd
0000a720 T sane_snapscan_init
00008370 T sane_snapscan_open
00006930 T sane_snapscan_read
000048e0 T sane_snapscan_set_io_mode
0000d2b0 T sane_snapscan_start
0000e650 T sane_start
0000e7b0 T sane_strstatus
What I worry about is having the dll backend provide the threading.
If you don't access a backend through the dll backend all of a sudden
your threading support disappears.
> if so, perhaps this intermediate loader could be linked as well...
You mean as many backends do nowadays with the sanei_* stuff? They
link with the sanei_* stuff statically to make sure that each and
every backend is a "free-standing" implementation. You could go the
route of linking dynamically with a libsanei and install that so the
backends can share it.
This approach may shave off a bit on installed size if you install all
(or many) SANE backends, but if you are targetting embedded devices
and only need a single backend you may be better of linking statically
Hope this helps,
Olaf Meeuwissen EPSON AVASYS Corporation, SE1
FSF Associate Member #1962 sign up at http://member.fsf.org/
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90
Penguin's lib! -- I hack, therefore I am -- LPIC-2
More information about the sane-standard