Why callback functions are static?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Jimmy

    #1

    Why callback functions are static?

    I need to use Asynchronous Socket functions in a server application and
    am learning from sources such as the MSDN2
    (http://msdn2.microsoft.com/en-us/library/bbx2eya8.aspx). What I
    observed is that all callback handlers in examples are static
    functions. I did try non-static callback handlers; they certainly
    works, and they usually make my code simpler.

    For example, a typical tutorial will start an asynchronous connection
    with:

    client.BeginCon nect(remoteEP, new AsyncCallback(C onnectCallback) ,
    client );

    and handle the results with:

    static void ConnectCallback (IAsyncResult ar) {
    ...
    }

    Because we cannot directly refer to any class member variables and
    functions in a static function, we will have to pack them into the "ar"
    parameter and pass them to the callback handler. In the above example,
    we passed the caller of the BeginConnect() function as the "ar", so we
    can get it back with "ar.AsyncState" .

    On the other hand, if non-static callback handlers are used, I usually
    don't need to pass anything in "ar". In the above example, I will be
    able to directly use the "client" in the ConnectCallback () (My
    BeginXXX() and handlers are in the same class).

    Can somebody please let me know if there will be any performance
    penalties if I go with the non-static callbacks? What was the reason
    for the penalties if there are any?

    I am also curious about how expensive the "new" operation, that coverts
    a callback function name to an AsyncCallback delegate, is. In case of
    reading and writing, my sever will need to process lots of them. So I
    am thinking of creating a member variable to hold the function
    references for the lifetime off an object.

    Any input will be very appreciated,
    Jimmy

  • Marc Gravell

    #2
    Re: Why callback functions are static?

    No performance problem; in the examples, the Connect method itself is
    static, so this is just a feature of the design of the example.
    Delegates work similarly (identically?) for static and non-static
    members, and instance will work fine.

    This type of thing is often the result of simple demo code falling
    directly from the (enforced) static Main() method...

    Marc

    Comment

    • DeveloperX

      #3
      Re: Why callback functions are static?


      Marc Gravell wrote:
      No performance problem; in the examples, the Connect method itself is
      static, so this is just a feature of the design of the example.
      Delegates work similarly (identically?) for static and non-static
      members, and instance will work fine.
      >
      This type of thing is often the result of simple demo code falling
      directly from the (enforced) static Main() method...
      >
      Marc
      I always assumed they did it that way so they didn't have to worry
      about concurrent access to member variables where a callback is raised
      from two threads. So it makes the example simpler and architectually
      correct, but certainly more confusing. I could well be wrong though :)
      Great question imo.

      Comment

      • Marc Gravell

        #4
        Re: Why callback functions are static?

        I always assumed they did it that way so they didn't have to worry
        about concurrent access to member variables where a callback is raised
        from two threads.
        Curiously, I always approach it the exact opposite way - i.e. an
        instance (non-static) method may, under cetain circumstances, have to
        be made thread safe, but static methods should *always* consider thread
        safety. Just being static doesn't (alone) enforce anything re thread
        safety, and static methods can happily reference static members, and so
        need sync. Conversely, with a non-static implementation, there is a
        reasonable chance (depending on the design) that each instance
        represents a separate request, and so we don't have to worry about sync
        - as each callback will be acting on a different instance.

        But yes - an intersting question / discussion topic.

        Marc

        Comment

        • Jimmy

          #5
          Re: Why callback functions are static?

          Thanks both of you! I was busy writing a piece of code testing the
          performance. It turns out, you guessed it, they are the same and Marc
          was right.

          Again, really appreciated!
          Jimmy

          Marc Gravell wrote:
          I always assumed they did it that way so they didn't have to worry
          about concurrent access to member variables where a callback is raised
          from two threads.
          >
          Curiously, I always approach it the exact opposite way - i.e. an
          instance (non-static) method may, under cetain circumstances, have to
          be made thread safe, but static methods should *always* consider thread
          safety. Just being static doesn't (alone) enforce anything re thread
          safety, and static methods can happily reference static members, and so
          need sync. Conversely, with a non-static implementation, there is a
          reasonable chance (depending on the design) that each instance
          represents a separate request, and so we don't have to worry about sync
          - as each callback will be acting on a different instance.
          >
          But yes - an intersting question / discussion topic.
          >
          Marc

          Comment

          Working...