> On Jun 13, 2017, at 11:56 AM, Brady Eidson <beid...@apple.com> wrote: > >> >> On Jun 13, 2017, at 9:55 AM, Filip Pizlo <fpi...@apple.com >> <mailto:fpi...@apple.com>> 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.
It seems that the benefit of keeping existing Function semantics is that it will sometimes prevent you from some races (but not all since as you say, you can still put the Function in a shared object). The benefit of merging Function and SharedTask is twofold: 1) JSC uses SharedTask in a lot of places not because we want to actually share it with many threads, but because RefPtr<> can be stored in a lot more kinds of data structures. I think there are places where we do some transformation on a set of tasks, and implementing it all using move semantics would be cumbersome. For example, most textbook sorting algorithms are most easily implemented if you can do “=“ and temporarily create aliases (or copies). This is the main reason why I find myself switching Function code to use SharedTask. 2) You won’t need a different type when you do want sharing between threads. I wrote SharedTask initially for this purpose, but this is usually not the reason why I use it. I get that being able to guarantee that (2) won’t happen is attractive, but I’m worried that using no-copy to ensure this makes other things harder. > >> 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. My goal is to see if we can merge SharedTask and Function. I don’t have opinions on how the two should be implemented. -Filip > > 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 <cdu...@apple.com >>> <mailto:cdu...@apple.com>> 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 <fpi...@apple.com >>>> <mailto:fpi...@apple.com>> 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 <da...@apple.com >>>>> <mailto:da...@apple.com>> 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 >>>>> 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 >> <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
