From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Guile's I/O procedures should *not* do thread synchronization Date: Wed, 26 Mar 2014 11:32:07 -0400 Message-ID: <87r45pht6w.fsf@yeeloong.lan> References: <1395746068-20604-1-git-send-email-dfsr@riseup.net> <87lhvys6ug.fsf@pobox.com> <87vbv1ilzl.fsf_-_@yeeloong.lan> <878urxpds1.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1395847993 17317 80.91.229.3 (26 Mar 2014 15:33:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Mar 2014 15:33:13 +0000 (UTC) Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 26 16:33:22 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WSppQ-0006SK-TU for guile-devel@m.gmane.org; Wed, 26 Mar 2014 16:33:21 +0100 Original-Received: from localhost ([::1]:48729 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSppQ-0001Rf-HQ for guile-devel@m.gmane.org; Wed, 26 Mar 2014 11:33:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43146) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSppJ-0001RJ-11 for guile-devel@gnu.org; Wed, 26 Mar 2014 11:33:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WSppD-0006bj-Vy for guile-devel@gnu.org; Wed, 26 Mar 2014 11:33:12 -0400 Original-Received: from world.peace.net ([96.39.62.75]:34836) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSppD-0006aF-TF for guile-devel@gnu.org; Wed, 26 Mar 2014 11:33:07 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong.lan) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WSpot-0005Cc-Nw; Wed, 26 Mar 2014 11:32:47 -0400 In-Reply-To: <878urxpds1.fsf@pobox.com> (Andy Wingo's message of "Wed, 26 Mar 2014 09:25:34 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17026 Archived-At: Andy Wingo writes: > On Wed 26 Mar 2014 06:10, Mark H Weaver writes: > >> Andy Wingo writes: > n> >>> On Tue 25 Mar 2014 12:14, "Diogo F. S. Ramos" writes: >>> >>>> It's not obvious that ports are not thread-safe and trying to have >>>> multiple threads writing to one returns errors that are not >>>> recognizable as been caused by this lack of thread-safeness. >>> >>> This is a bug, and it is fixed in master. FWIW. >> >> FWIW, I disagree that this is a bug. I continue to believe that it >> would be a very serious mistake to promise to do thread synchronization >> within Guile's standard I/O procedures. > > It seems to work for glibc streams. Why do you think that thread > synchronization is inappropriate for Guile if it works for glibc? glibc implements the POSIX API, which (1) mandates that the I/O functions do thread synchronization, and (2) provides standard alternatives that avoid thread synchronization. In the Scheme world, things are very different. The Scheme standards provide only one set of I/O primitives, and do not mandate that they do thread synchronization. >> However, if we promise to do thread synchronization, we will condemn >> Guile to forever having dog slow 'read-char', 'peek-char', 'write-char', >> 'get-u8', 'peek-u8', and 'put-u8' operations. > > I think you are wrong about "dog slow". Uncontended mutexes are fast, I did some benchmarks of 'putchar' vs 'putchar_unlocked' in C, without contention. I think it's fair to assume that the GCC and GLIBC folks did a reasonably good job of making both of these as fast as they could. Here's my test program: --8<---------------cut here---------------start------------->8--- #include int main (int argc, char *argv[]) { int i = 100000000; char ch = 'a'; while (i--) { putchar (ch); if (ch == 'z') ch = 'a'; else ch++; } } --8<---------------cut here---------------end--------------->8--- With gcc -O2, I tested two variants of this program: one with 'putchar' and one with 'putchar_unlocked'. On my YeeLoong (mips64el w/ N32 ABI), the 'putchar_unlocked' version is faster by a factor of 26.3. > and we can disable mutexen entirely for certain ports. What set of ports would you suggest? What about when portable programs do I/O on stdin and stdout? Since you ignored my strongest point, I'll repeat it: Finally, robust programs will have to do their own explicit synchronization anyway. Multiple threads writing to the same port without explicit synchronization would lead to garbled output that is interleaved at unspecified points. The situation is even worse on the read side. In order to do proper I/O on the same port from multiple threads, the locking _must_ be done within code that understands the meaning of the data being read or written, because only such code can know where the data can be interleaved without producing garbage. Regards, Mark