From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 95851395C000 for ; Mon, 29 Aug 2022 23:54:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 95851395C000 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661817291; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=VOuB+MLv3NysVtuDjp8cuII84ZWQvvPBhlCWUVpriic=; b=KEi2xlzoQmrTzgttrGtFccBRCPVNzTOF9qAXXXY2GFIo5aU4zdesY3E629aGS3tleSuVxm QnN99Rsz+uNPXV/yxtSXF6DwVC2cRnBTXDlERU/hw5xGCvqh4KbtrjwKtnTL/pw5uAuA2N UYc6WEmiAN7GhOEL4gJ+KAQ5ez8cJFQ= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-159-PhNZI_8sMcarM8_GwebMnw-1; Mon, 29 Aug 2022 19:54:50 -0400 X-MC-Unique: PhNZI_8sMcarM8_GwebMnw-1 Received: by mail-qk1-f197.google.com with SMTP id bl16-20020a05620a1a9000b006bc3aa1908dso7859402qkb.15 for ; Mon, 29 Aug 2022 16:54:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc; bh=VOuB+MLv3NysVtuDjp8cuII84ZWQvvPBhlCWUVpriic=; b=4/0Pxv/kDAMvXhvJcNX23ob8XycmpnUOijDgJ5uLUz9bjATqLG1/uFLkXCOpTlZZuD qIKwSwgTEBzYAvWAZETQebMBlz/NwcDgWZHYhZvm6M8Webs9ORfccdyPUxNfGPocdSSl ftmLMpA7vNEqndnGw3HYncDGQQ3kMuQ9Mb2SP3JP/H3d+iw7dMBG9SylH/syAlhIKToh P7vI/4iOcI3uVpQaOT/SiHOYGWc8lH3jqPBCXhjQ7I8gGKWLhiqtFet+Jf3XUvngkP58 +CsYL0JAqwpBsGXSco2NeTlAVcSxbhIAqcZqsslH4/iXpl1BQOo+uhWjCjBBZne2P+8W W9ZQ== X-Gm-Message-State: ACgBeo02Yay+FHFGSnCiuIIpTDgTlKleGF6Ln/90nl8LEL6FuhkI+dLg W4GvgU/DYPVXnvMxM+ZHNbzPp7yfl2iRb70lEJLbIdyBj0rSEkwuLdJLv3Wuw9O9RbjTes8hKkM +FKNMeTuAsmRsqVio8FVj5vR+GoDE1nGGErA3i529 X-Received: by 2002:a05:620a:57b:b0:6bb:f708:589f with SMTP id p27-20020a05620a057b00b006bbf708589fmr10278445qkp.112.1661817289616; Mon, 29 Aug 2022 16:54:49 -0700 (PDT) X-Google-Smtp-Source: AA6agR6H5AodJYbmIWsDED+nfH0znj70bdhJL/6X9WNKWvR6qMCPnNqhSIFZU4pmMBGg0MOyjMA3mmIPAh+TeWt2+vQ= X-Received: by 2002:a05:620a:57b:b0:6bb:f708:589f with SMTP id p27-20020a05620a057b00b006bbf708589fmr10278432qkp.112.1661817289377; Mon, 29 Aug 2022 16:54:49 -0700 (PDT) MIME-Version: 1.0 From: Aaron Merey Date: Mon, 29 Aug 2022 19:54:38 -0400 Message-ID: Subject: Worker threads and MHD_USE_EPOLL To: elfutils-devel@sourceware.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: The debuginfod man page states that if the server is run without the --connection-pool option, a new thread will be cloned for every request. However this is not always the case. Since commit e646e363e debuginfod attempts to configure the libmicrohttpd daemon to use epoll for the daemon's internal event loop. libmicrohttpd requires that if epoll support is enabled, it will not create a new thread to handle each request. So when the --connection-pool option is not given, the daemon ends up configured to use a just a single worker thread that can only respond to one request at a time. There are a few ways we can address this. My preferred approach is to use MHD_USE_THREAD_PER_CONNECTION instead of MHD_USE_EPOLL when --connection-pool is not given. This preserves the behaviour stated in the man page and if users want the performance benefits of epoll they can always use --connection-pool to enable it. If we insist on always using epoll when it's available then we might want to change the default number of worker threads to something other than 1, just like when --connection-pool is given with no argument. We could simply modify the man page to state that if --connection-pool isn't given then only 1 worker thread will be used. However I don't like this approach because it unnecessarily constrains the server's default behavior and ideally we should try to preserve the behavior that we advertise in the man page. WDYT? Aaron