> On Jun 13, 2017, at 9:55 AM, Filip Pizlo <[email protected]> wrote: > > Would SharedTask’s sharing be semantically incorrect for users of > WTF::Function? In other words, do you rely on the compiler error that says > that there is no copy constructor?
WTF::Function is used in cross-thread dispatching, where arguments captured by the lambda are “thread safe copied”, “isolated copied”, etc. Part of the safety is the lack of a copy constructor, as accidentally making a copy on the originating thread can invalidate the setup for thread safety. So, yes, they must maintain move-only semantics. > I’m imagining that if WTF::Function was backed by SharedTask that it would > not result in any behavior change for existing WTF::Function users. I see the reverse. Is there any reason SharedTask can’t be backed by a WTF::Function? There’s no harm in adding Ref counting semantics on top the move-only WTF::Function if SharedTask is your goal. Thanks, Brady > At worst, it would mean that WTF::Function’s backing store has an extra word > for the ref count - but if you only move and never copy then this word starts > out at 1 and stays there until death, so it’s very cheap. > > -Filip > > >> On Jun 13, 2017, at 9:43 AM, Chris Dumez <[email protected] >> <mailto:[email protected]>> wrote: >> >> In most cases in WebCore at least, we don’t actually want to share ownership >> of the lambda so we don’t need RefCounting / SharedTask. Because of this, I >> don’t think we should merge SharedTask into Function. I think that as it >> stands, WTF::Function is a suitable replacement for most uses in WebCore >> since we actually very rarely need copying (either it just builds or the >> code can be refactored very slightly to avoid the copying). >> >> -- >> Chris Dumez >> >> >> >> >>> On Jun 13, 2017, at 9:34 AM, Filip Pizlo <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> We should have a better story here. Right now the story is too >>> complicated. We have: >>> >>> - ScopedLambda or ScopedLambdaRef if you have a stack-allocated function >>> that outlives its user >>> - SharedTask if you have a heap-allocated function that you want to share >>> and ref-count >>> - WTF::Function if you have a heap-allocated function that you want to >>> transfer ownership (move yes, copy no) >>> - std::function if you have a heap-alloated function that you want to pass >>> by copy >>> >>> Only std::function and WTF::Function do the magic that lets you say: >>> >>> std::function f = <lambda> >>> >>> Also, std::function has the benefit that it does copying. None of the >>> others do that. >>> >>> ScopedLambda serves a specific purpose: it avoids allocation. Probably we >>> want to keep that one even if we merge the others. >>> >>> IMO SharedTask has the nicest semantics. I don’t ever want the activation >>> of the function to be copied. In my experience I always want sharing if >>> more than one reference to the function exists. I think that what we >>> really want in most places is a WTF::Function that has sharing semantics >>> like SharedTask. That would let us get rid of std::function and SharedTask. >>> >>> In the current status quo, it’s not always correct to convert std::function >>> to the others because: >>> >>> - Unlike ScopedLambda and SharedTask, std::function has the magic >>> constructor that allows you to just assign a lambda to it. >>> - Unlike ScopedLambda, std::function is safe if the use is not scoped. >>> - Unlike WTF::Function, std::function can be copied. >>> >>> -Filip >>> >>> >>>> On Jun 13, 2017, at 9:24 AM, Darin Adler <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> I’ve noticed many patches switching us from std::function to WTF::Function >>>> recently, to fix problems with copying and thread safety. >>>> >>>> Does std::function have any advantages over WTF::Function? Should we ever >>>> prefer std::function, or should we use WTF::Function everywhere in WebKit >>>> where we would otherwise use std::function? >>>> >>>> — Darin >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >> > > _______________________________________________ > webkit-dev mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
