How to prevent overlapping calls to read?

[moefear85]

Hi,

I'm a noob in both fuse and python-fuse. I've implemented the read(...) callback, but when I access a file from the outside, the read callback gets executed concurrently more than once, and even though I'm trying to access the data in order, the size and offset arguments passed to read seem to indicate it is getting called out of order (non-sequentially).

How do I prevent this? I don't want another call to read() to be triggered before the first one has fully completed.

Also, the mount options are a bit confusing. How do I pass command line arguments when I'm not creating the Fuse object from the command line? I'd like to let any user, specifically root, be able to access the fuse filesystem even when it's running as a normal user process.

[glensc]

without knowing the internals of fuse or this library, you can prevent concurrent access with lock:

• https://superfastpython.com/lock-vs-semaphore-in-python/

[moefear85]

thx im using them. i also discovered the -s option.

[glensc]

yeah, I wanted to point out that there's dash_s_do option controlling multithreading:

• python-fuse/fuse.py

  Lines 211 to 236 in e6c876f

  	dash_s_do
  	String: ``whine``, ``undef``, or ``setsingle`` [default is ``whine``].
  	The ``-s`` option -- traditionally for asking for single-threadedness --
  	is an oddball: single/multi threadedness of a fuse-py fs doesn't depend
  	on the FUSE command line, we have direct control over it.
  	Therefore we have two conflicting principles:
  	- *Orthogonality*: option parsing shouldn't affect the backing `Fuse`
  	instance directly, only via its `fuse_args` attribute.
  	- *POLS*: behave like other FUSE based fs-es do. The stock FUSE help
  	makes mention of ``-s`` as a single-threadedness setter.
  	So, if we follow POLS and implement a conventional ``-s`` option, then
  	we have to go beyond the `fuse_args` attribute and set the respective
  	Fuse attribute directly, hence violating orthogonality.
  	We let the fs authors make their choice: ``dash_s_do=undef`` leaves this
  	option unhandled, and the fs author can add a handler as she desires.
  	``dash_s_do=setsingle`` enables the traditional behaviour.
  	Using ``dash_s_do=setsingle`` is not problematic at all, but we want fs
  	authors be aware of the particularity of ``-s``, therefore the default is
  	the ``dash_s_do=whine`` setting which raises an exception for ``-s`` and
  	suggests the user to read this documentation.

it's set to setsingle in examples, it's where you usually start with? :)