[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs