Issue posted, https://github.com/libuv/libuv/issues/387. Thanks!
On Tue, Jun 2, 2015 at 4:29 PM, Fedor Indutny <[email protected]> wrote: > Yeah, the compatibility is a problem as usual. > > It sounds very interesting to explore it behind the v1.x, maybe I'll work > on it if someone will create an issue on github and cc me ;) > > Thank you for asking this! > > On Tue, Jun 2, 2015 at 5:56 PM, Curtis Yarvin <[email protected]> > wrote: > >> Yes, it looks like that fd is opened just because there's an fd field in >> the handle and otherwise it could get lonely ;-) >> >> There are already OSX version ifdefs in the code so another probably >> won't hurt. Glad to hear this problem exists only because it's a low >> priority and not because there's a fundamental obstacle. >> >> On Tue, Jun 2, 2015 at 12:50 AM, Saúl Ibarra Corretgé <[email protected]> >> wrote: >> >>> Hi, >>> >>> On 06/02/2015 02:21 AM, [email protected] wrote: >>> > As far as I can tell, libuv on OS X uses FSEvents to watch directories >>> > but kqueue to watch files, resulting in one open fd per watched file. >>> > Combined with OS X's insanely small default fd table, this makes it >>> > tough to build a dropbox style sync utility on top of libuv. >>> > >>> >>> FAIS we still open an fd when FSEvents is used, which should be solvable. >>> >>> > The FSEvents doc says that since 10.7, FSEvents can watch files as well >>> > as directories. But the libuv code still seems to test for S_IFDIR and >>> > otherwise goto fallback (kqueue). >>> > >>> > I'm wondering whether a pure FSEvents file watcher isn't in libuv >>> > because it wouldn't work for some reason, or because it's just a low >>> > priority. If the latter, I'd be happy to try and come up with a patch. >>> > >>> >>> Fedor can probably give you a better answer, but probably it has to do >>> with the fact that OSX < 10.7 is still supported (ish). Personally, I'm >>> open to the debate of dumping support for OSX < 10.8, but we should >>> probably preserve it in v1.x, dumping it in master should be fine though. >>> >>> You're more than welcome to write a patch for it and improve it, of >>> course! >>> >>> >>> Cheers, >>> >>> -- >>> Saúl Ibarra Corretgé >>> bettercallsaghul.com >>> >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "libuv" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/libuv/IlZlhWilF5E/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/libuv. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "libuv" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/libuv. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "libuv" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/libuv/IlZlhWilF5E/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/libuv. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
