Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#21356 closed Cleanup/optimization (fixed)

Instant auto-reloading on BSD / OS X

Reported by: Aymeric Augustin Owned by: nobody
Component: Core (Other) Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no


In the wake of #9722, I'd like to implement the same feature on OS X, preferably without external dependencies.

Pull request:

However, I'm often seeing two or three reloads in a row when a single file in changed. I'm not sure where that behavior comes from. Thoughts?

Change History (7)

comment:1 Changed 9 years ago by Aymeric Augustin

Has patch: set
Patch needs improvement: set

comment:2 Changed 9 years ago by loic84

I would limit the fflags to:

fflags = (
    select.KQ_NOTE_DELETE |
    select.KQ_NOTE_WRITE |
    select.KQ_NOTE_EXTEND |

I suspect the reason for the multiple reloads is that modern text editors do all sorts of fancy things to files, which could trigger extra events.

With the previous set of fflags, I haven't managed to trigger more than one event by using the touch command, while my text editor (PyCharm) would reload almost at every key stroke.

With the restricted set of fflags, I only get a reload when the changes are committed, which is the expected outcome.

comment:3 Changed 9 years ago by Aymeric Augustin <aymeric.augustin@…>

Resolution: fixed
Status: newclosed

In a023a84c060eaaa4cf520c33d9c73adab7af3d30:

Merge pull request #1830 from aaugustin/instant-reload-os-x

Add instant autoreload on platforms supporting kqueue.

Fix #21356.

comment:4 Changed 9 years ago by loic84

I'm getting a ValueError: current limit exceeds maximum limit.

This happens in the PyCharm console, but not in the terminal.

resource.getrlimit returns (10240, 9223372036854775807) in PyCharm and (256, 9223372036854775807) in the terminal.

The issue is 10240 is actually the kernel limit for my system as demonstrated by sysctl kern.maxfilesperproc; so when we do NOFILES_SOFT + len(filenames) we try to go over the kernel hard limit which causes the ValueError.

It's not clear to me why the second return value of resource.getrlimit is not equal to the actual kernel hard limit...

I'm not sure how to proceed at this point.

comment:6 Changed 9 years ago by Aymeric Augustin

Here's an alternative solution that gets the actual limit from the kernel.

comment:7 Changed 9 years ago by Aymeric Augustin <aymeric.augustin@…>

In 2bba0d275bdf392deb144a6e83392a80d57c8c03:

Improved resource limits handling in the kqueue autoreloader.

Refs #21356. Thanks Loïc.

Note: See TracTickets for help on using tickets.
Back to Top