Hi Johannes, To answer this with confidence I'd probably have to be writing the code myself in order to force myself to think about all the issues. Since I'm not writing it, I can only try to tell you some points you might consider, but in the end it's up to you to decide what will work best.
FWIW, I generally avoid .detach() like the plague, as it almost always leads to problems. A detached promise cannot be canceled, so it is essential that it directly owns all the data structures it will operate on, or you need some sort of guarantee that the objects won't be destroyed before the promise completes. I find that it's really easy to believe that you have this guarantee when in most cases you actually don't. For example, throwing an exception commonly unwinds the stack, causing objects to be summarily destroyed while they're in the middle of doing things. Detached promises can thus easily turn exceptions into segmentation faults. The two-promise idea could work but seems weird. I haven't really tried that approach before. So I would recommend trying to use returned promises. Perhaps this will require some convoluted logic to handle the case where the timer is enabled/disabled during the callback, but I feel like this should not be too bad. -Kenton On Wed, Feb 1, 2017 at 3:44 AM, Johannes Zeppenfeld <[email protected]> wrote: > Hi Kenton, > > thanks for the suggestion! Would you say that returning the new promise is > so much preferable that it is worth jumping through some extra hoops for it? > > The problem is that the user's callback function may call the enable or > disable methods of the callback arbitrarily (especially for other callback > types, e.g. DelayCallback, that do not reschedule themselves by default). > Both methods would have to know if the callback is currently executing. If > not, they would have to schedule the callback themselves, otherwise they > would have to inform the caller whether to reschedule the callback or not. > As is (by detaching the executing promise), the enable method can simply > schedule the callback, blindly (over)writing the promise in the > implementation struct, and disable can simply assign nullptr to the > promise, without caring who the caller is. > > As for running kj on top of libev, I looked into the example you linked, > but decided that, especially since I use quite a lot of timers, it would be > cleaner to use only a single event library, especially since all uses of > libev were already wrapped in a custom event system interface. > > Thanks! > Johannes > > -- > You received this message because you are subscribed to the Google Groups > "Cap'n Proto" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at https://groups.google.com/group/capnproto. > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
