Henning Meier-Geinitz wrote:
> At least on Linux, saned will exit even if you kill -9 xsane. I don't
> understand all details but maybe that's because of signal (SIGPIPE, quit)
> in saned.c. So maybe this is for other platforms?
Not only for other platforms.
1) When xsane crashes saned does not exit
2) When the system crashes on which xsane does run saned will not exit.
3) When the network connection is interrupted saned does not exit.
> I haven't looked into details but don't we need some sort of locking for
> this? What happens, if some data is transmitted through the net and in
> this moment the forked process starts its sane_get_option_descriptor (handle, 0)
Yes, we have to care about such things. So may be it could be easier
to force that GUI frontends have to call a sane_control_option()
e.g. every 60 seconds... but this also is not nice.
> > May be we could define a well_known_option "create_keepalives" that can be
> > set by GUI-frontends, so for command-line-frontends the fork() is not called.
> I'm not sure if this is necessary as the keep-alive shouldn't harm
> command-line frontends (it's just not necessary).
Yes, but forking means at least a lot of unnecessary memory usage.
> I will change the alarm to 3600 seconds for now.
-- Homepage: http://www.rauch-domain.de sane-umax: http://www.rauch-domain.de/sane-umax xsane: http://www.xsane.org E-Mail: mailto:Oliver.Rauch@rauch-domain.de
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail firstname.lastname@example.org
This archive was generated by hypermail 2b29 : Tue Jun 05 2001 - 11:17:13 PDT