Repository navigation
Status of timers enroll/unenroll/active #896
Description
The timers module exposes some functions (enroll, unenroll, active) that allow for the implementation of efficient idle timers and are used for this purpose by the builtin http module.
I'd like to make some changes to these APIs in a semver-minor patch, but the status of these APIs is currently unclear.
These functions aren't documented and their use outside of core seems very limited.
My proposal is to define them as being private and renaming them to '_enroll', '_unenroll' etc. as part of the next change.
Comments? @iojs/tc
Activity
trevnorris commentedon Feb 19, 2015
If it's in heavy use by user-land then I'm not for changing them. Otherwise +1 on the idea.
mikeal commentedon Feb 19, 2015
I've been working on a tool that could tell us how many modules in npm use a particular core module, either themselves or through one of their dependencies. It sounds like it would be useful here :)
bnoordhuis commentedon Feb 19, 2015
FWIW, a quick if non-exhaustive GH code search doesn't turn up any projects that use enroll/unenroll.
mikeal commentedon Feb 19, 2015
wow... if GH code search finds nothing then I'm pretty confident nobody is actually using this :)
cjihrig commentedon Feb 19, 2015
I'm also +1 if it's not in use. I'd be surprised if it was. I recently updated
enroll()and it was only used like twice in core IIRC.mikeal commentedon Feb 19, 2015
I was able to find a few, looks like mostly people using or building polyfills for browserify though https://github.com/search?l=javascript&q=timers.enroll&ref=searchresults&type=Code&utf8=%E2%9C%93
Fishrock123 commentedon May 13, 2015
@chrisdickinson maybe you could run this against your packages thing?
Fishrock123 commentedon May 26, 2015
@piscisaureus what changes were you planning to do to them?
Fishrock123 commentedon Jun 24, 2015
See: http://logs.libuv.org/io.js/2015-06-24#23:15:56.833
Bert's request was (basically) to make them always act like
_unrefActive.Trott commentedon Mar 11, 2016
@Fishrock123 Is the plan to first deprecate
active(),enroll(), andunenroll()and then make them private at some semver-major point in time? Or something else?Would it be useful to see if @ChALkeR can pull up some rough usage stats for userland module?
Fishrock123 commentedon Mar 16, 2016
@Trott I think we should probably actually keep them, undocumented.
They are non-problematic and unlikely to ever require significant changes imo.
Closing this, re-open if necessary.