[webkit-dev] Should we ever use std::function instead of WTF::Function?

[Brady Eidson]

> On Jun 13, 2017, at 9:55 AM, Filip Pizlo <fpizlo at 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.

> 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 <cdumez at apple.com <mailto:cdumez at 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 <fpizlo at apple.com <mailto:fpizlo at 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 <darin at apple.com <mailto:darin at 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 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
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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