From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 66CA61FAF4 for ; Tue, 6 Mar 2018 08:42:43 +0000 (UTC) From: "Eric Wong (Contractor, The Linux Foundation)" To: meta@public-inbox.org Subject: [PATCH 17/34] searchidxskeleton: add a note about locking Date: Tue, 6 Mar 2018 08:42:25 +0000 Message-Id: <20180306084242.19988-18-e@80x24.org> In-Reply-To: <20180306084242.19988-1-e@80x24.org> References: <20180306084242.19988-1-e@80x24.org> List-Id: It's tempting to rely on the atomicity of smaller-than-PIPE_BUF writes, but it doesn't work if mixed with larger ones. --- lib/PublicInbox/SearchIdxSkeleton.pm | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/PublicInbox/SearchIdxSkeleton.pm b/lib/PublicInbox/SearchIdxSkeleton.pm index 063c83e..506e566 100644 --- a/lib/PublicInbox/SearchIdxSkeleton.pm +++ b/lib/PublicInbox/SearchIdxSkeleton.pm @@ -80,6 +80,8 @@ sub index_skeleton { $str = length($str) . "\n" . $str; # multiple processes write to the same pipe, so use flock + # We can't avoid this lock for <=PIPE_BUF writes, either, + # because those atomic writes can break up >PIPE_BUF ones $self->_lock_acquire; print $w $str or $err = $!; $self->_lock_release; -- EW