[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #27299 [Core Tor/Tor]: hsv3: Clarify timing sources around hsv3 code
#27299: hsv3: Clarify timing sources around hsv3 code
-------------------------------------------------+-------------------------
Reporter: asn | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-hs hsv3 refactoring easy | Actual Points:
technical-debt |
Parent ID: #23764 | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by asn):
Replying to [comment:5 ffmancera]:
> Replying to [comment:3 asn]:
> > > I saw that we are using `approx_time()` which is an alias of
`time(NULL)`, but at the same time and in the same file, we are using
both. As `approx_time.h` has different utilities for timing, we should use
it instead of `time(NULL)`. What do you think?
> > >
> >
> > Yes, I think we should be using `approx_time()` instead of
`time(NULL)` everywhere. I don't see a reason not to.
> >
> > One of the problems with HS timing is that lots of the time sources
come from the main event loop where `time(NULL)` is used.
>
> Then we should refactor all time resources, using only approx_time()
over all the code right? I have a patch for this specific task. I will do
a pull request if you are fine with that :-)
You mean ALL over the codebase? Not sure how to evaluate the correctness
of such a refactoring. Do you think there is a clear way to show that it
does not break anything or change any behavior?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27299#comment:6>
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