Re: [Xenomai-core] Analogy: cancel ongoing commands when a device is closed

[Alexis Berlemont <alexis.berlemont@domain.hid>]

Hi,

Alexis Berlemont wrote:
> Hi,
> 
> Daniele Nicolodi wrote:
> > Alexis Berlemont wrote:
> > > Daniele Nicolodi wrote:
> > >> After fixing analogy to permit continuous acquisition, I discovered that
> > >> ongoing commands are not canceled when a device is closed (I obtain a
> > >> DMA buffer owerwrite warning in the kernel log when I abruptly terminate
> > >>  my acquisition program).
> > >>
> > >> I think this is quite a surprising behavior. I would expect that the
> > >> commands are canceled when there isn't a data consumer any more. Would
> > >> it be possible to cancel any ongoing command on device close? If there
> > >> is agreement on this, I can look into providing a patch.
> > >>
> > > The close should indeed stop any occurring acquisition. I implemented
> > > this behaviour. It is in my git repository.
> > 
> > Hi Alexis. I have been working with analogy from your git three and I
> > should say that the new behavior, in my use case, is worst than the
> > previous.
> > 
> > Now, when a device is closed, all accurring acquisition are terminated,
> > also the ones that haven't been started by the current process. While it
> > is possible to use at the same time two different subdevices, from two
> > different processes, now it is not possible to terminate one process and
> > leave the other one running. I think that the correct behavior would be
> > to terminate just the acquisitions started by the current process.
> > However, I have no idea on how difficult this would be.
> > 
> 

I just pushed into the branch analogy of my git repository what you
asked. Starting from now, the only asynchronous acquisition to be
cancelled will be the one which is related with the file descriptor to
be closed.

I reviewed the Analogy core to do so. You should not notice any API /
ABI breakage.

> We had two alternatives: either stopping nothing or cancelling "any
> ongoing command" related with the device. Cancelling only acquisitions
> initiated by a specific process implies the implementation of some
> tricky mechanism above the file approach (open, ioctl, close). I am
> afraid that we will create some complex code for an issue which should
> be solved by a suitable device file organization (maybe many dev files
> instead of a single one). 
> 
> I will have a look at what you asked but I cannot ensure anything, I
> have no clear solution in mind.
> 
> > This bring me also to the fact that there isn't currently a way to
> > prevent two concurrent processes to access the same subdevice,
> > interfering each other. Would it possible to have a lock() method, as
> > comedi has?
> 
> There is a lock mechanism but it is not exposed as it is in
> comedi. The lock system is at the subdevice level: you cannot initiate
> an instruction if a command is occuring (the reverse is true of
> course). This is handled with a subdevice status bitfield atomically
> accessed. Have a look at a4l_reserve_transfer() and tell me if I miss
> something. 
> 
> > 
> > Thanks. Cheers,
> > -- 
> > Daniele
> > 
> > _______________________________________________
> > Xenomai-core mailing list
> > Xenomai-core@domain.hid
> > https://mail.gna.org/listinfo/xenomai-core
> 
> -- 
> Alexis.

-- 
Alexis.