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