From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server-vie001.gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_DBL_BLOCKED_OPENDNS, URIBL_ZEN_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=3.4.6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org; s=new2025; t=1755406663; bh=kV8+FHilY+bfkQ+TKek15QYXvbUu2jGYYjrgYC3lQX8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To:Message-ID:Date:From:Reply-To:Subject:To: Cc:In-Reply-To:References:Resent-Date:Resent-From:Resent-To: Resent-Cc:User-Agent:Content-Type:Content-Transfer-Encoding; b=V/YKhkVLEMCK+ohTpyE91LIWbtinbzD+v/yo/q59Q65ANGuainm6Oe+R7HJgj8Won tQvQuJmuPugblYsUfFhbQws5EFMYcpT1CDcC/9vTmD/S9TK2plATOLWNbdruINYpXb 6deilmP+9eq4fiABu2XvX2k8SzUymd25loadw8wEwIn0soL6wun2f3M4xpFyCsiBxa zfPJtPq5a9CLDIPiXcD/wZWPVDyoE5AMTzBlp/x/oYqf82JwOUp7oyIlzad/QiaTiu JXKxgEgvjIfj3YYxcoSzPjNDAwkod6qxq7NE79FrKW5QRElWX4INLA+8biwm357TQN x6CwPCCKSmPmA== Received: from linux.gnuweeb.org (unknown [182.253.126.185]) by server-vie001.gnuweeb.org (Postfix) with ESMTPSA id 344613127EA2; Sun, 17 Aug 2025 04:57:42 +0000 (UTC) Date: Sun, 17 Aug 2025 11:57:39 +0700 From: Ammar Faizi To: Ahmad Gani Cc: Alviro Iskandar Setiawan , GNU/Weeb Mailing List Subject: Re: [PATCH gwproxy v0] epoll: Improve log readability and efficiency Message-ID: <20250817045739.GA553171-ammarfaizi2@gnuweeb.org> References: <20250817031621.81090-1-reyuki@gnuweeb.org> <20250817043750.GA545393-ammarfaizi2@gnuweeb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Gw-Outgoing-Server-Hash: 01afd303c8b96d0c1d5e80aa96a4ee40ec69888f786fa24107c0862c0644af79 X-Gw-Message-ID: 5c46269fc9dabb2947703f7097f7a38e123031c27d6694806b941fc4ad27a79b X-Gw-PM-Hash: 2a6e87df643846cc901fdd082eda0ab9ca110ca6f1b7f25529dcc2c8bec076e2 List-Id: On Sun, Aug 17, 2025 at 11:49:13AM +0700, Ahmad Gani wrote: > By the way, I wonder why GWP_CONN_FLAG_NO_CLOSE_FD exists? Can you explain > the use cases for such a thing to exist? > > Wouldn't it cause a file descriptor leak too? I should have explained it better. GWP_CONN_FLAG_NO_CLOSE_FD is only used from the io_uring case. __sys_close() is a heavy syscall and better be done asynchronously via prep_close() in io_uring context. GWP_CONN_FLAG_NO_CLOSE_FD allows log_conn_pair_close() to log the fd numbers without the obligation to call __sys_close() in free_conn(). Previously, it was confusing to debug when the fd is set to -1 by the gwp_free_conn_pair()'s caller. GWP_CONN_FLAG_NO_CLOSE_FD simply means the fds are no longer owned by gcp. -- Ammar Faizi