[sane-devel] pthreads for MacOSX (instead of child process)

[abel deuring]

Henning Meier-Geinitz wrote:
> Hi,
> 
> On Thu, Feb 06, 2003 at 01:30:18AM +0100, abel deuring wrote:
> 
>><flame>
>>Did they also bother to explain, why no device files are available which 
>>should not have this problem (well, hoping that device file descriptors 
>>would survive a fork() on Macos)?
>></flame>
> 
> 
> Maybe nobody thought that someone could fork a program instead just
> use threads. Threads are modern, nobody uses fork anymore! :-)
> 
> I thought part of the Unix philosophy was "everything is a file"?
> </rant>

I thought that too. Can we conclude that OS/2 is more unix-like with 
respect to device handling than macos x?

While I appreaciate Beat's effort to port Sane to Macos, I must admit to 
have some serious prejudices towards Apple. Why should we support their 
operating system, when they don't bother to port for example quicktime 
players to Linux, *BSD or some other Unix variant?

I also had a short look into Apple's mailing list archives. The answers 
to a question by Beat regarding device access from forked processes seem 
to indicate there is really not hope. The main reason seems to be "too 
complicated to implement for Mach". (BTW, the archives of older mailings 
are the worst organized archives I have seen since a long time. So much 
for the shiny surface of Apple stuff...)

But ranting doesn't help much. Let's go back to work ;)

> 
>>>Maybe the libusb one day provides a workaround.
> 
> 
> If there is no way to get access priviledge from iokit, I don't think
> libusb can do anything.
> 
> If there is a way, we can do it also in sanei_usb.

Somebody proposed to the apple mailing list to start a sort of a daemon 
which accesses the device. Since sockets (pipes too?) seem to survive a 
fork on macos, this could indeed be a way to avoid the current fork 
hassles. Other ways would be to provide a non-forking version of the 
backend (like the Sharp and NEC backends do), or to make the backends 
thread-safe (should not be that much work, since the tasks of the two 
processes/threads are different enough), and to expand the sanei_thread 
library.

> 
> There is a similar issue with parport access. Access permissions have
> to be regained after a fork. 
> 
> 
>>Well, you could try to reverse to roles of parent and child after the 
>>fork: the parent could control the scanner, while the child talks with 
>>the frontend... Naaa, I should go to bed...
> 
> 
> Won't work: when you kill the process after the scan you kill the
> frontend you just talked to :-)

Yes, I know that a trivial reversal of the roles of the two processes 
would not be enough. I didn't mean this to be a serious proposal -- I 
simply tried to apply Apple's slogan "think different" ;)

Abel