[webkit-dev] Proposal: Do not support Windows fibers

[Geoffrey Garen]

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 <msaboff at 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 <msaboff at apple.com <mailto:msaboff at 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 <rniwa at webkit.org <mailto:rniwa at 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.tea at gmail.com <mailto:utatane.tea at 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 at lists.webkit.org <mailto:webkit-dev at 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 at lists.webkit.org <mailto:webkit-dev at 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 at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20171205/77f19aa9/attachment.html>