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

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue May 10 20:30:54 UTC 2016


#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:17 nickm]:
 > Oh, wrt the "quite a number of symbols declared outside of any macro" --
 which symbols did you have in mind?

 Well, all of them!  To wit:
 * pubsub_subscriber_fn_t
 * pubsub_subscriber_t
 * pubsub_topic_t
 * pubsub_subscribe_
 * pubsub_unsubscribe_
 * pubsub_clear_
 * pubsub_notify_fn_t
 * pubsub_notify_

 These are implementation details, nobody should be using them.  So, why
 even allow it?  Why gratuitously polluting the namespace of every consumer
 of "pubsub.h"?

 Replying to [comment:18 nickm]:
 > Okay, both of the above issues should be 'resolved'.  I've solved the
 concurrent-modification problem by just forbidding it for now; we can
 allow it later if needed.

 Yeah, no.  Not unless you change the data structure behind.  I've looked a
 bit at the smrtlist functions/macros now, and indeed they are just
 relocatable arrays, so that's certainly not going to fly against reentrant
 calls (not something easy to avoid once you have this convenient callback
 machinery; call trees can grow complicated pretty quickly).

 (PS: You said nothing about s/DEFINE/DECLARE/g.)

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


More information about the tor-bugs mailing list