Kyle Lippincott

> Let's also be a bit more specific in the commit message: with this change, we are explicitly accepting that write requests through the high level API may never complete...

> > This would not solve the current issue, as the current issue is entirely in the > > It is waiting in a pthread-cond-wait. I meant to avoid doing...

> I mean to introduce a new f->rw_lock. Typically the code would take a read-lock. Once it detects that there is a lock conflict - i.e. wants to put itself...

I've discovered an issue with this change as-is, I'm working on understanding/resolving these issues now.

I apologize, I'm unfamiliar with github pull request workflows, do I need to mark the requested changes as having been done or responded to in some way? I've applied this...

Anything needed from me?

In case it's helpful: we've had this deployed for months now in at least 3 different filesystems on our developer workstations and there have been no reports of issues from...

Looks like it was https://github.com/libfuse/libfuse/commit/66956b6f7a254517332fe6e1fa3efab1676e6239, which doesn't have an explanation of the concern (besides the comment). The only starvation issue I could identify, since we support reader locks, would be...

In the threads below, thread 5 is attempting to rename `/tmp/hello/rmthis/foo/file.txt` to `/tmp/hello/rmthis/bar/file.txt`, while thread 4 is attempting to delete `/tmp/hello/rmthis`. The nodeids are as follows, and I've put the...

`f->lock` is only held while acquiring a “lock” (not a pthread based lock) on the individual nodes (by manipulating the treelock property of the nodes themselves). The lock that’s acquired...