From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id C33A71F44D for ; Thu, 28 Mar 2024 08:33:11 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=dhnf0Zov; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=yhbt.net header.i=@yhbt.net header.a=rsa-sha256 header.s=selector1 header.b=LXOm3+3+; dkim-atps=neutral Received: from nue.mailmanlists.eu (localhost [127.0.0.1]) by nue.mailmanlists.eu (Postfix) with ESMTP id E522583900; Thu, 28 Mar 2024 08:33:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1711614782; bh=Dgo+ianEXZj1C07HihMfQG36Whlnp3hEFxZ1XEXlzd4=; h=Date:To:References:In-Reply-To:Reply-To:Subject:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From:Cc:From; b=dhnf0Zovk9pLQPUtPsEDsqZjEo0eO9ucHTSsfJr4Rf+fBCTkmSHl3NlSL3buVb6MP ca8fv9xAkXRKEBZy6BPD/lIPbRUxM48sdy33ESYh9281KlE3x0SuQQQOir6kjSsLSs t8vbQplWx+OXyRkIXNOx25twx2QetJQ4SnJOaFFw= Received: from dcvr.yhbt.net (dcvr.yhbt.net [173.255.242.215]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 385F683842 for ; Thu, 28 Mar 2024 08:32:59 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (1024-bit key; unprotected) header.d=yhbt.net header.i=@yhbt.net header.a=rsa-sha256 header.s=selector1 header.b=LXOm3+3+; dkim-atps=neutral Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 6B5781F44D; Thu, 28 Mar 2024 08:32:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yhbt.net; s=selector1; t=1711614777; bh=POjP/en1f36zEcDGUfJt5XXTOUXRgWu7u5Qj0U+M/dQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=LXOm3+3+gUHsdUqhv0I8dUktaWAm76PtZENB7wMbiD0/5N0ZKeAj7ES1Y5lLXdpEc 8g5gllvojq1Au4a9gIBTOeJ77DJGNlh1cIo7OhxR4686QQOWzq4DBI4LhQeyhKP37V zRvw5fTL86Rmw4VqaLPRcU+EvVHEeo00bcPnFRQc= Date: Thu, 28 Mar 2024 08:32:57 +0000 To: ruby-core@ml.ruby-lang.org Message-ID: <20240328083257.M319689@dcvr> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Message-ID-Hash: 7KQ2CKZ546VJJPJWIQ5GOMZG2UBJQ73H X-Message-ID-Hash: 7KQ2CKZ546VJJPJWIQ5GOMZG2UBJQ73H X-MailFrom: normalperson@yhbt.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.3 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:117361] Re: [Ruby master Feature#19057] Hide implementation of `rb_io_t`. List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: Eric Wong via ruby-core Cc: Eric Wong Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit "ioquatix (Samuel Williams) via ruby-core" wrote: > Issue #19057 has been updated by ioquatix (Samuel Williams). > > > > Why don't you reconsider the "nested public interface" approach? > > My assessment of this approach is that it would require a rewrite of all internal code that accesses `rb_io_t` internals. Rewriting code isn't a problem, but it takes a lot of time and effort that I don't have in abundance right now. Additionally, it's still only a partial solution. One of the issues is accessing the file descriptor directly and the handling of `IO#close` from a different thread/fiber. Using the file descriptor directly can be problematic. Again, why not the container_of solution I proposed? It shouldn't be that much for you since the relevant core internals could be divorced from extensions and significantly less work for stressed out and overworked downstream maintainers. Cross-thread IO#close or close(2) is a PITA to deal with portably if another thread is using that FD in any way. This applies to pure C projects, too, not just Ruby ones. Either: 1) ensure only one thread operates on a given FD and closes it; this is typical for stream FDs. 2) get all threads to abandon the FD before closing it. I do this for thread-shared packetized FDs which are analogous to Queue (O_DIRECT pipe, SOCK_SEQPACKET, listen sockets, kqueue/epoll FDs, etc...). Atomics + out-of-band (pthread_kill) signaling work for both cases. I've also used sentinel values in-band for packetized FDs (analogous to pushing `:stop' messages into a thread-shared Queue, like forcing a connect() in one thread to get blocking accept() to wake up; or adding an (eventfd||pipe) into a (kqueue||epoll) from another thread (it's 100% safe to EPOLL_CTL_ADD||EV_ADD from different threads and I've been abusing this safety for well over a decade) > > Ruby lost numerous users due to a never-ending stream of incompatibilities introduced every year. > > Compatibility and progress are always something to balance out. I think on the whole, Ruby does a pretty decent job at it. Lack of forward progress also causes users to look elsewhere as the language stagnates. So this isn't just. a matter of "preserve compatibility at all costs", as those costs will be the same. The hard part is finding the middle ground of compatibility and progress. Both compatibility at any cost, and progress at any cost, are naive statements. git and Linux kernel do a pretty good job at maintaining compatibility while adding new features. OTOH some of the incompatibility proposals for Perl 5 have made me look into writing more C... ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/