[sane-devel] RE: (Big?) Problem with fork() in OSX
Hi, On Wed, Dec 18, 2002 at 04:42:46PM +0100, abel deuring wrote: > Theoretically, it could be possible to replace the fork call with > somethink like "sane_fork". There is already a sanei_thread.h which solves fork problems for OS/2. > For sane (i.e., non-darwin) operating > systems, this function would just call fork; for Macos, sane_fork could > additionally duplicate/reopen all necessary, hmmm, "non-filedescriptors" > which are required by the child process to access the scanner. The > necessary information could be collected by sanei_scsi_open or > sanei_usb_open. Nice idea. But sanei_usb doesn't know anything about MacOS. It just uses libusb. So if there is no libusb_regain_access(), I don't think we can do anything here. Bye, Henning
[sane-devel] RE: (Big?) Problem with fork() in OSX
Henning Meier-Geinitz wrote: > > Hi, > > On Wed, Dec 18, 2002 at 02:39:47PM -, Phil Barrett wrote: > > The problem is that after you call (*taskinferface->ObtainExclusiveAccess)() > > a fork()ed thread is then denied access because the first thread has > > exclusive access. > > I thought fork creates new processes not threads? > > I don't see how to workaround such problems in SANE. > > I don't even see how to workaround it in libusb if there is no way to > regain acces in the child process. > > Isn't there any way to make sure that childrens of the current process > can access the already opened devices? > > Otherwise I guess Mac OS X and SANE is a no-go at least for some > backends. well, the Apple folks sometimes have crazy ideas. Think about these unusable round mice sold with older IMacs. Theoretically, it could be possible to replace the fork call with somethink like "sane_fork". For sane (i.e., non-darwin) operating systems, this function would just call fork; for Macos, sane_fork could additionally duplicate/reopen all necessary, hmmm, "non-filedescriptors" which are required by the child process to access the scanner. The necessary information could be collected by sanei_scsi_open or sanei_usb_open. Abel
[sane-devel] RE: (Big?) Problem with fork() in OSX
Hi, On Wed, Dec 18, 2002 at 02:39:47PM -, Phil Barrett wrote: > The problem is that after you call (*taskinferface->ObtainExclusiveAccess)() > a fork()ed thread is then denied access because the first thread has > exclusive access. I thought fork creates new processes not threads? I don't see how to workaround such problems in SANE. I don't even see how to workaround it in libusb if there is no way to regain acces in the child process. Isn't there any way to make sure that childrens of the current process can access the already opened devices? Otherwise I guess Mac OS X and SANE is a no-go at least for some backends. Bye, Henning
[sane-devel] RE: (Big?) Problem with fork() in OSX
> If the file descriptors aren't dup'ed, that should be fixed on MacOS > and not SANE. That's one of the basic Unix functions and if it doesn't > work, it's just not Unix. > > However, bugs in fork would harm a lot of other applications so I > wonder if this is the real reason. There are no bugs in fork() or with file descriptors (or at least, none relevant to the current discussion). The problem is that Mac OS X IO access is not (and indeed cannot be) made through file descriptors. The Darwin IO libraries are another breed completely. See http://developer.apple.com/techpubs/macosx/Darwin/IOKit/DeviceInterfaces/SCS IArchitectureModel/SAMDocPage.html The problem is that after you call (*taskinferface->ObtainExclusiveAccess)() a fork()ed thread is then denied access because the first thread has exclusive access. Phil
[sane-devel] RE: (Big?) Problem with fork() in OSX
Hi, On Tue, Dec 17, 2002 at 06:46:33PM +0100, Jaeger, Gerhard wrote: > As the Plustek backend is not the only one that forks > a reader process, the question should be how can this be solved > for OSX? > Any ideas? > One might be the approach to have two versions one using > the fork and one without (USE_FORK i.e. nec.c)... If it's already implemented in the backend, it could be switched off in configure. However, I wouldn't put much effort in eliminating fork just because some operating system has problems with it. > But I thought, that fork duplicates the entire process environment... If the file descriptors aren't dup'ed, that should be fixed on MacOS and not SANE. That's one of the basic Unix functions and if it doesn't work, it's just not Unix. However, bugs in fork would harm a lot of other applications so I wonder if this is the real reason. Bye, Henning
[sane-devel] RE: (Big?) Problem with fork() in OSX
As the Plustek backend is not the only one that forks a reader process, the question should be how can this be solved for OSX? Any ideas? One might be the approach to have two versions one using the fork and one without (USE_FORK i.e. nec.c)... But I thought, that fork duplicates the entire process environment... Gerhard On Tuesday, 17. December 2002 15:33, Phil Barrett wrote: > Beat Birkhofer wrote: > > In plustek.c in the function sane_start() there's a fork(). Just > > after calling this fork() the connection to the USB is broken > > (IOService fails). > > If it's anything like the SCSI side, which I looked at a long while back, > this is because the access to the interface is exclusively given to the > thread that opened it. I had the HP (I think - it might have been another > one) driver working fine until the point where it fork()ed to receive the > scan data. > > Phil
[sane-devel] RE: (Big?) Problem with fork() in OSX
Beat Birkhofer wrote: > In plustek.c in the function sane_start() there's a fork(). Just > after calling this fork() the connection to the USB is broken > (IOService fails). If it's anything like the SCSI side, which I looked at a long while back, this is because the access to the interface is exclusively given to the thread that opened it. I had the HP (I think - it might have been another one) driver working fine until the point where it fork()ed to receive the scan data. Phil
