Bump minimatch from 3.0.4 to 3.1.2

[dependabot[bot]]

Bumps minimatch from 3.0.4 to 3.1.2.

Commits

• 699c459 3.1.2
• 2f2b5ff fix: trim pattern
• 25d7c0d 3.1.1
• 55dda29 fix: treat nocase:true as always having magic
• 5e1fb8d 3.1.0
• f8145c5 Add 'allowWindowsEscape' option
• 570e8b1 add publishConfig for v3 publishes
• 5b7cd33 3.0.6
• 20b4b56 [fix] revert all breaking syntax changes
• 2ff0388 document, expose, and test 'partial:true' option
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

[ericphanson]

can you explain your use-case more, why do you want to grab the lock over multiple gets/sets?

[ericphanson]

ReentrantLock seems preferred in general over SpinLock reading through the julia issue tracker / PRs, so it would make sense to me to switch. But I assume @jutho had a reason for choosing SpinLock in the first place. Maybe we can try to do some benchmarking to see what the tradeoffs are.

[Jutho]

I think I chose the SpinLock because it was claimed to be more performant, and I assumed that the requirements for using it were fulfilled. But I have very little experience with multithreaded code and locks and all the unexpected complications that can arise, so a ReentrantLock might be the safer solution.

I am interested in the use case here. The goal is that LRU takes care of the locking in a way that is oblivious to the user, so the user should not manually have to interfere with this. If you are trying to build a solution were you need to manually control the lock, is it even worth using LRU. Then again, I could see that you maybe want to recycle part of the implementation, so I am definitely open to this suggestion.

[gbrgr]

Please apologize the delayed reply, I missed that thread. Regarding the question as what is the use case of taking a lock over multiple gets/sets, one simple example is where one would like to implement a method which acts as get_or_new:

function get_or_new(cache::LRU{K,V}, key::K, args...)
    lock(cache) do
        if haskey(cache, key)
            cache[key]
        else
            created = V(args...)
            cache[key] = created
            return created
        end
    end
end

Now such user-level locks become easiest if one uses a ReentrantLock, as otherwise users of LRU would have to allocate their own lock, as they cannot re-lock SpinLock.

[ericphanson]

I think this specific api is provided already: https://github.com/JuliaCollections/LRUCache.jl#getdefaultcallable-lrulru-key

[gbrgr]

Thanks I missed that. In any case, I think it might be worth considering changing that lock in case performance gains can be made.