Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
D
dhcp
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 72
    • Issues 72
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 18
    • Merge Requests 18
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • ISC Open Source Projects
  • dhcp
  • Issues
  • #76

Closed
Open
Opened Jan 10, 2020 by Thomas Markwalder@tmarkMaintainer

Add a version of dhcpctl_wait_completion() that accepts a timeout

Per support ticket:

https://support.isc.org/Ticket/Display.html?id=15842

Calling dhcpctl_wait_completion() has two shortcomings:

  1. First, it does not provide a timeout parameter and thus may effectively hang
  2. Underneath the covers the way the logic is structured in omapi/dispatch.c, we end up effectively using the select() calls to poll in a tight loop eating CPU.

The first issue is simply address. The latter is a bit more sticky. The select calls are with omapi_dispatch_one(). They monitor the read and write sides of OMAPI connections. However, once the basic socket connection is made, the write side virtually ALWAYS tests as ready to write, thus even passing in a timeout value as shown in the second call below:

isc_result_t omapi_one_dispatch (omapi_object_t *wo,
                                 struct timeval *t)
{
  :
        /* poll once */
        count = select(max + 1, &r, &w, &x, &now);
        if (!count) {
                /* We are dry now */
                trigger_event(&rw_queue_empty);
                /* Wait for a packet or a timeout... XXX */
                r = rr;
                w = ww;
                x = xx;
                count = select(max + 1, &r, &w, &x, t ? &to : NULL);
        }
:

results in an immediate return from select. Thus we should only test the write side of the socket for readiness to write if we are connected AND we have data to write.

Assignee
Assign to
4.4.3
Milestone
4.4.3
Assign milestone
Time tracking
None
Due date
None
Reference: isc-projects/dhcp#76