[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_revision
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:12 dgoulet]:
> * I think a `pubsub_free_` would be useful because right this leaks the
`static pubsub_topic_t name ## _topic_ = { NULL, 0 };`.
dgoulet, dude!
> 2) Why is `DEFINE_PUBSUB_TOPIC` and `DEFINE_NOTIFY_PUBSUB_TOPIC` are
separated? I feel like _not_ having a notify function defined will end up
breaking `IMPLEMENT_PUBSUB_TOPIC` so maybe merge them together?
>
> 3) Is there a reason why only the `notify` and `clear` can have a
different linkage? I can see myself wanting _all_ the functions `static`.
It's supposed to be an inter-module facility, remember? Think about it.
(Though, about the linkage: it may actually be useful to have the option
anyway.)
(Also: `DEFINE_*` should really be `DECLARE_*`, definition is the same as
implementation.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18363#comment:13>
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