Project

General

Profile

Actions

Feature #2442

closed

Re-license and move ScopedEventId (generalized) implementation from NFD codebase

Added by Alex Afanasyev almost 10 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Category:
Utils
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

ScopedEventId can be useful in many other places besides NFD. The only difference that ScopedEventId in the library should not be tied to global scheduler instance.

As a result, there is interface change and one interface limitation (no longer possible to implicitly convert EventId to ScopedEventId).
Here is a modified version of API:

/** \brief Event that is automatically cancelled upon destruction
 */
class ScopedEventId : noncopyable
{
public:
  /** \brief Construct ScopedEventId tied to the specified scheduler
   *  \param scheduler Scheduler to which the event is tied
   */
  ScopedEventId(Scheduler& scheduler);

  /** \brief move constructor
   */
  ScopedEventId(ScopedEventId&& other);

  /** \brief assigns an event
   *
   *  If a different event has been assigned to this instance previously,
   *  that event will be cancelled immediately.
   *
   *  \note The caller should ensure that ScopedEventId is tied to a correct scheduler.
   *        Behavior is undefined when assigning event scheduled in another scheduler instance.
   */
  ScopedEventId&
  operator=(const EventId& event);

  /** \brief cancels the event
   */
  ~ScopedEventId();

  /** \brief cancels the event manually
   */
  void
  cancel();

  /** \brief releases the event so that it won't be disconnected
   *         when this ScopedEventId is destructed
   */
  void
  release();

private:
  Scheduler* m_scheduler; // pointer to allow move semantics
  EventId m_event;
};
Actions #1

Updated by Alex Afanasyev almost 10 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100
Actions #2

Updated by Junxiao Shi almost 10 years ago

What's the reason for ndn-cxx not to have a global io_service and scheduler?

Actions #3

Updated by Alex Afanasyev almost 10 years ago

Because the library should not enforce a single io_service among different elements. For example, the library should not prevent creating multiple threads with independent io_service and scheduler objects in each.

Actions #4

Updated by Junxiao Shi almost 10 years ago

I agree with the statement in note-3.

What about adding a reference to Scheduler inside EventId?

Actions #5

Updated by Alex Afanasyev almost 10 years ago

I would keep things as is for now. Adding reference to scheduler inside EventId is kind of a big change and I don't yet want to have it.

Actions #6

Updated by Alex Afanasyev almost 10 years ago

  • Status changed from Resolved to Code review
Actions #7

Updated by Junxiao Shi almost 10 years ago

  • Status changed from Code review to Closed
  • Start date deleted (01/28/2015)
Actions

Also available in: Atom PDF