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: Guile's I/O procedures should *not* do thread synchronization Date: Wed, 26 Mar 2014 01:10:06 -0400 Message-ID: <87vbv1ilzl.fsf_-_@yeeloong.lan> References: <1395746068-20604-1-git-send-email-dfsr@riseup.net> <87lhvys6ug.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1395810704 26084 80.91.229.3 (26 Mar 2014 05:11:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Mar 2014 05:11:44 +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 06:11:53 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 1WSg80-00029v-JX for guile-devel@m.gmane.org; Wed, 26 Mar 2014 06:11:52 +0100 Original-Received: from localhost ([::1]:45621 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSg7z-0005Pg-NA for guile-devel@m.gmane.org; Wed, 26 Mar 2014 01:11:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51250) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSg7r-0005PT-1E for guile-devel@gnu.org; Wed, 26 Mar 2014 01:11:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WSg7l-0003Hm-Jz for guile-devel@gnu.org; Wed, 26 Mar 2014 01:11:42 -0400 Original-Received: from world.peace.net ([96.39.62.75]:34218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSg7l-0003HP-Fl for guile-devel@gnu.org; Wed, 26 Mar 2014 01:11:37 -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 1WSg7H-0003lx-TI; Wed, 26 Mar 2014 01:11:08 -0400 In-Reply-To: <87lhvys6ug.fsf@pobox.com> (Andy Wingo's message of "Tue, 25 Mar 2014 15:14:47 +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:17023 Archived-At: Andy Wingo writes: > 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. Standard Scheme programs that do their own parsing and printing using 'read-char', 'peek-char' and 'write-char' could be made at least an order of magnitude faster in the future if we don't make this promise. This could be done in a future version of Guile by uniformly using a fixed encoding (UTF-8 or maybe UTF-32) for the port buffers of textual ports, and doing the coding conversion when the buffer is filled or flushed. 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. Consider string ports, for example. They could be the basis for a very natural and efficient method of writing string operations, especially when we move to UTF-8 encoding of strings internally and string indexing becomes less efficient, but only if we have fast single-character I/O. In Guile's own internal read and print procedures, a global find-replace was done in master to change all of these simple port operations to use unlocked variants, presumably because it would have caused a major performance regression otherwise. What's the plan for portable Scheme code that implements similar functionality, such as Oleg's libraries? Most ports (by far) are only accessed by a single thread, but everyone would have to pay the hefty price of built-in thread synchronization whether they need it or not. 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. For all of these reasons, I would strongly urge us to reconsider the decision to promise internal locking for Guile's I/O procedures. Regards, Mark