[tor-bugs] #18363 [Core Tor/Tor]: Tor could use a publish/subscribe abstraction

[Tor Bug Tracker & Wiki]

#18363: Tor could use a publish/subscribe abstraction
-------------------------------------------------+-------------------------
 Reporter:  nickm                                |          Owner:  nickm
     Type:  enhancement                          |         Status:
 Priority:  High                                 |  needs_review
Component:  Core Tor/Tor                         |      Milestone:  Tor:
 Severity:  Normal                               |  0.2.9.x-final
 Keywords:  modularity, tor-modularity,          |        Version:
  TorCoreTeam201605, TorCoreTeam-                |     Resolution:
  postponed-201604                               |  Actual Points:
Parent ID:                                       |         Points:  medium
 Reviewer:  dgoulet                              |        Sponsor:
                                                 |  SponsorS-can
-------------------------------------------------+-------------------------

Comment (by cypherpunks):

 Replying to [comment:20 nickm]:
 > > Why gratuitously polluting the namespace of every consumer of
 "pubsub.h"?
 >
 > The implementation macros use these functions.  The alternative would be
 to rename them and stick them in the macros.  That didn't seem to have
 much point IMO.

 Errh.  Why would you need to rename them?  AFAICS, you could simply put
 them all at the beginning of the IMPLEMENT macro, for example.

 In "pubsub.c" you only need the types.  It would be great if it were
 possible to put them in a header and include this from both "pubsub.c" and
 the IMPLEMENT macro, but that doesn't work, right?  In any case,
 repetition can be avoided if the include inside the macro is scripted (a
 pre-preprocessing step).

 Hmm.  Well, at least the function prototypes can be easily hidden away in
 the macro.

 > > Yeah, no.
 >
 > Please spell it out for me.

 Oh, I think I quoted too much and confused you.  I actually think it's
 fine now with the "locked" guard.  When I said "no" I was actually
 referring only to this part:
 > we can allow it later if needed.

 And I qualified that: "unless...".  And I believe you already agree with
 me in this, that's why you added the "locked" thing, right?  But 2
 examples anyway:
 * Call unsubscribe while inside a notification handler: `_del_keeporder`
 moves the array content and reduces the length; `_FOREACH` is oblivious.
 * Call subscribe while inside a notification handler: `_insert` moves the
 array content, relocates memory (this one is not be a problem in single-
 threading? there's one further indirection? not sure, will check again
 later), and increases the length; `_FOREACH` is oblivious.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18363#comment:21>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online