[sane-standard] SANE2: Threading

[Olaf Meeuwissen]

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:
>>
>>> [snip]
>>> 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
to libsanei.

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