RFC: future executor
authorJames Sedgwick <jsedgwick@fb.com>
Fri, 26 Sep 2014 15:56:56 +0000 (08:56 -0700)
committerAnton Likhtarov <alikhtarov@fb.com>
Fri, 26 Sep 2014 22:26:49 +0000 (15:26 -0700)
commit61386620a957a4cb58457146be182c4702b4027b
treee0006c7caaea9bb3890c60a407c4a12d8c617473
parentfa43917d8aad3fb20bcd5005c4b5cd524aeb149b
RFC: future executor

Summary:
not necessarily for commit but i was playing around a bit with this today to see what it might look like, so i figured i'd put it up
i assume this shenanigan isn't remotely safe (threadwise) without some extra magic... @fugalh we chatted about this last time i was in mpk a bit.
maybe addFuture could take an executor to make sure the promise is fulfilled on the correct thread, or something.

you'd have to reimplement timeouts via this executor or via futures if you wanted to get them via the futures channel, which makes sense anyway as this could be used with any Executor and not just ThreadPoolExecutor which owns that implementation

also specialized makeFutureTry to take functions that return futures but treat them like they return the contained types, so fulfil() can be used liked then()
this specialization could just as easily be done on fulfil() itself if we wanted.

Test Plan: unit

Reviewed By: davejwatson@fb.com

Subscribers: hannesr, trunkagent, craffert, njormrod, fugalh, bmatheny

FB internal diff: D1566369
folly/experimental/wangle/concurrent/FutureExecutor.h [new file with mode: 0644]
folly/experimental/wangle/concurrent/test/ThreadPoolExecutorTest.cpp