Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support time limit on generation #3

Open
wahern opened this issue May 14, 2015 · 0 comments
Open

Support time limit on generation #3

wahern opened this issue May 14, 2015 · 0 comments

Comments

@wahern
Copy link
Owner

wahern commented May 14, 2015

Support optional time limit on function generation. Although CHD can complete in bounded time (at least given a uniformly random hashing primitive), most applications really only care about constraining actual processor or wall time consumed. Trying to estimate the cost beforehand is problematic, especially for large sets, because of memory latency issues and dynamic system load.

Applications cannot interrupt generation themselves without leaking the memory we use for our temporary arrays.

Some non-exclusive options:

  1. longjmp from a signal handler triggered by alarm, setitimer, or timer_create. Need to worry about threading issues: posix_sigmask versus sigprocmask, sigaction installing global handler, etc. Probably best to only use timer_create and set the struct sigevent sigval member to point to the jmp_buf. This is probably the most performant option, at least for moderate to large key sets.
  2. Check sig_atomic_t flag which is set by a timer_create sigevent handler. Here we set the sigval member to point to the sig_atomic_t flag. A little simpler than the longjmp solution as we don't have to worry about using volatile qualifiers.
  3. Periodically check a system clock (clock, gettimeofday, clock_monotonic, etc). Fewer portability problems. None if using clock, but clock might be cumulative across all threads.
  4. Use getrusage to query CPU time. Definite threading issues. Would only want to use if RUSAGE_THREAD or RUSAGE_LWP available.
  5. Simply allow the application to specify a callback which we invoke periodically. The return value controls whether to fail generation. Portable and simple, but not very convenient for portable applications, which will have to tackle the above issues.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant