Project

General

Profile

Actions

Feature #2658

open

Face::unregisterPrefix and Face::unsetInterestFilter(RegisteredPrefixHandle): success/failure callbacks

Added by Alex Afanasyev over 9 years ago. Updated almost 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Base
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Given both operations are async, we need to allow application to specify success/failure callbacks.

Actions #1

Updated by Junxiao Shi over 9 years ago

  • Tracker changed from Task to Feature
  • Subject changed from Face::unregisterPrefix and Face::unsetInterestFilter(RegisteredPrefixId*) should accept success/failure callbacks to Face::unregisterPrefix and Face::unsetInterestFilter(RegisteredPrefixId*): success/failure callbacks

This Feature is correct but not important.

Once either function is invoked, app stops receiving Interests because handler is removed from Face's internal FIB.

App doesn't care when NFD's Route is unregistered.

Actions #2

Updated by Alex Afanasyev almost 9 years ago

  • Target version changed from v0.4 to v0.5

There is a potential problem of not having the callback. Operations are async (=they are scheduled in IO thread).

If the app is written that it destroys the face or the corresponding callback just after the call to unregisterPrefix/unsetInterestFilter, there is still a chance of the callback to be dispatched which can result in segfault.

I agree that this feature is low priority, but would be good to have.

Actions #3

Updated by Junxiao Shi almost 8 years ago

  • Target version changed from v0.5 to v0.6

It seems that Face::unregisterPrefix already has success/failure callbacks. An Face::unsetInterestFilter overload does not have success/failure callbacks, but its implementation is exactly same as Face::unregisterPrefix.
How about deprecating Face::unsetInterestFilter overload in favor of Face::unregisterPrefix?

If the app is written that it destroys the face or the corresponding callback just after the call to unregisterPrefix/unsetInterestFilter, there is still a chance of the callback to be dispatched which can result in segfault.

I cannot reproduce this situation. valgrind isn't complaining on the snippet below. I guess ndn-cxx:commit:ae0b418784aa1b021797190d0e56abb95a386b3c has fixed the problem.

// g++ -o x -std=c++0x x.cpp $(pkg-config --cflags --libs libndn-cxx)
#include <ndn-cxx/face.hpp>
#include <boost/asio.hpp>

using namespace ndn;

int main()
{
  boost::asio::io_service io;
  Face* face = new Face(io);
  const RegisteredPrefixId* rpid = face->registerPrefix("/A",
    bind([] { std::cout << "register-success\n"; }),
    bind([] { std::cout << "register-failure\n"; }));
  face->processEvents(time::milliseconds(500));
  face->unregisterPrefix(rpid,
    bind([] { std::cout << "unregister-success\n"; }),
    bind([] { std::cout << "unregister-failure\n"; }));
  delete face;
  io.run();
  return 0;
}
Actions #4

Updated by Davide Pesavento almost 7 years ago

  • Target version deleted (v0.6)
Actions #5

Updated by Davide Pesavento almost 6 years ago

  • Subject changed from Face::unregisterPrefix and Face::unsetInterestFilter(RegisteredPrefixId*): success/failure callbacks to Face::unregisterPrefix and Face::unsetInterestFilter(RegisteredPrefixHandle): success/failure callbacks
Actions #6

Updated by Junxiao Shi almost 6 years ago

Now that the preferred way of unregistering is RegisteredPrefixHandle::unregister that accepts callbacks. I just need to deprecate the old way, and this issue would be gone.

Actions

Also available in: Atom PDF