If our Windows clients are cool with it, I think we should remove support for fibers.
I don’t think our current implementation works super well with fibers. It is best not to include half-working code in the tree. Geoff > On Dec 5, 2017, at 11:19 AM, Michael Saboff <msab...@apple.com> wrote: > > Here is the reply from iTunes for the WebKit-Dev list > > - Michael > > —— > > From an iTunes perspective, WebKit can eliminate any remaining Windows Fiber > API support. > > iTunes still uses some cooperative threading, but implements its own > mechanism on top of regular preemptive Windows threads. And we believe we've > fixed all occurrences of calling WebKit/JSC from our non-main cooperative > threads. > > - John > >> On Dec 5, 2017, at 10:26 AM, Michael Saboff <msab...@apple.com >> <mailto:msab...@apple.com>> wrote: >> >> [Bringing John Lehner from the iTunes team into the discussion] >> >> Last I knew, the iTunes team uses fibers. IIRC, the thread they use to call >> into WebKit/JSC only has one fiber, other parts of the app use multiple >> fibers on one thread but don’t have JS objects active in those threads / >> fibers. >> >> John, have things changed for iTunes on Windows such that we can eliminate >> support for fibers? >> >> - Michael >> >>> On Dec 5, 2017, at 10:16 AM, Ryosuke Niwa <rn...@webkit.org >>> <mailto:rn...@webkit.org>> wrote: >>> >>> Yeah, I don't think there is much need to support fibers. With features >>> like web workers, supporting fibers doesn't make much sense. >>> >>> - R. Niwa >>> >>> On Tue, Dec 5, 2017 at 9:44 AM, Yusuke SUZUKI <utatane....@gmail.com >>> <mailto:utatane....@gmail.com>> wrote: >>> Hi, Webkittens, >>> >>> I would like to make sure OR declare that WebKit does not support Windows >>> fibers. >>> While fiber related functions are used in WTF, I believe that it is because >>> fiber local storage (FLS) can have destructors. And it is not intended to >>> support fibers explicitly. >>> >>> Actually, I believe the current WebKit does not work well with Windows >>> fibers right now. >>> For example, our JSC GC is conservative for stack and registers. It means >>> that GC needs to scan stack and registers to gather conservative roots. But >>> if your fiber is not executed at that time, JSC GC will miss to scan the >>> stack and registers of those inactive fibers. As a result, managed objects >>> will be collected if it is only referenced from the roots in the inactive >>> fibers. >>> >>> And I think we can potentially improve performance of our TLS by using >>> thread_local implementation in VC++ instead of using FLS. FLS is slow and >>> it causes some problems[1]. I'm not sure the performance characteristics >>> and implementation details of thread_local in VC++, but it's worth checking. >>> >>> So, I think we should not support Windows fibers. I would like to hear >>> opinions about it. >>> >>> [1]: https://bugs.webkit.org/show_bug.cgi?id=146448 >>> <https://bugs.webkit.org/show_bug.cgi?id=146448> >>> >>> Best regards, >>> Yusuke Suzuki >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >>> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
