From: Eric Wong <e@80x24.org>
Date: Tue, 21 Mar 2023 23:07:16 +0000 (+0000)
Subject: ipc: move nproc_shards from v2writable
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9225145d;p=thirdparty%2Fpublic-inbox.git

ipc: move nproc_shards from v2writable

We'll be using nproc_shards for indexing non-Inbox stuff.
---

diff --git a/lib/PublicInbox/IPC.pm b/lib/PublicInbox/IPC.pm
index 548a72ebb..730f2cf6b 100644
--- a/lib/PublicInbox/IPC.pm
+++ b/lib/PublicInbox/IPC.pm
@@ -19,7 +19,7 @@ use PublicInbox::WQWorker;
 use Socket qw(AF_UNIX MSG_EOR SOCK_STREAM);
 my $MY_MAX_ARG_STRLEN = 4096 * 33; # extra 4K for serialization
 my $SEQPACKET = eval { Socket::SOCK_SEQPACKET() }; # portable enough?
-our @EXPORT_OK = qw(ipc_freeze ipc_thaw);
+our @EXPORT_OK = qw(ipc_freeze ipc_thaw nproc_shards);
 my ($enc, $dec);
 # ->imports at BEGIN turns sereal_*_with_object into custom ops on 5.14+
 # and eliminate method call overhead
@@ -454,4 +454,28 @@ sub detect_nproc () {
 	undef
 }
 
+# SATA storage lags behind what CPUs are capable of, so relying on
+# nproc(1) can be misleading and having extra Xapian shards is a
+# waste of FDs and space.  It can also lead to excessive IO latency
+# and slow things down.  Users on NVME or other fast storage can
+# use the NPROC env or switches in our script/public-inbox-* programs
+# to increase Xapian shards
+our $NPROC_MAX_DEFAULT = 4;
+
+sub nproc_shards ($) {
+	my ($creat_opt) = @_;
+	my $n = $creat_opt->{nproc} if ref($creat_opt) eq 'HASH';
+	$n //= $ENV{NPROC};
+	if (!$n) {
+		# assume 2 cores if not detectable or zero
+		state $NPROC_DETECTED = PublicInbox::IPC::detect_nproc() || 2;
+		$n = $NPROC_DETECTED;
+		$n = $NPROC_MAX_DEFAULT if $n > $NPROC_MAX_DEFAULT;
+	}
+
+	# subtract for the main process and git-fast-import
+	$n -= 1;
+	$n < 1 ? 1 : $n;
+}
+
 1;
diff --git a/lib/PublicInbox/V2Writable.pm b/lib/PublicInbox/V2Writable.pm
index ed5182ae8..d3d139410 100644
--- a/lib/PublicInbox/V2Writable.pm
+++ b/lib/PublicInbox/V2Writable.pm
@@ -8,7 +8,7 @@ use strict;
 use v5.10.1;
 use parent qw(PublicInbox::Lock PublicInbox::IPC);
 use PublicInbox::SearchIdxShard;
-use PublicInbox::IPC;
+use PublicInbox::IPC qw(nproc_shards);
 use PublicInbox::Eml;
 use PublicInbox::Git;
 use PublicInbox::Import;
@@ -29,30 +29,6 @@ my $OID = qr/[a-f0-9]{40,}/;
 # an estimate of the post-packed size to the raw uncompressed size
 our $PACKING_FACTOR = 0.4;
 
-# SATA storage lags behind what CPUs are capable of, so relying on
-# nproc(1) can be misleading and having extra Xapian shards is a
-# waste of FDs and space.  It can also lead to excessive IO latency
-# and slow things down.  Users on NVME or other fast storage can
-# use the NPROC env or switches in our script/public-inbox-* programs
-# to increase Xapian shards
-our $NPROC_MAX_DEFAULT = 4;
-
-sub nproc_shards ($) {
-	my ($creat_opt) = @_;
-	my $n = $creat_opt->{nproc} if ref($creat_opt) eq 'HASH';
-	$n //= $ENV{NPROC};
-	if (!$n) {
-		# assume 2 cores if not detectable or zero
-		state $NPROC_DETECTED = PublicInbox::IPC::detect_nproc() || 2;
-		$n = $NPROC_DETECTED;
-		$n = $NPROC_MAX_DEFAULT if $n > $NPROC_MAX_DEFAULT;
-	}
-
-	# subtract for the main process and git-fast-import
-	$n -= 1;
-	$n < 1 ? 1 : $n;
-}
-
 sub count_shards ($) {
 	my ($self) = @_;
 	# always load existing shards in case core count changes: