From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: Guile's I/O procedures should *not* do thread synchronization Date: Wed, 26 Mar 2014 09:25:34 +0100 Message-ID: <878urxpds1.fsf@pobox.com> References: <1395746068-20604-1-git-send-email-dfsr@riseup.net> <87lhvys6ug.fsf@pobox.com> <87vbv1ilzl.fsf_-_@yeeloong.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1395822349 15722 80.91.229.3 (26 Mar 2014 08:25:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Mar 2014 08:25:49 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 26 09:26:00 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 1WSj9r-0000Tn-5D for guile-devel@m.gmane.org; Wed, 26 Mar 2014 09:25:59 +0100 Original-Received: from localhost ([::1]:46199 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSj9q-0003k6-LP for guile-devel@m.gmane.org; Wed, 26 Mar 2014 04:25:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55150) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSj9g-0003dQ-P2 for guile-devel@gnu.org; Wed, 26 Mar 2014 04:25:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WSj9Z-0000c2-RU for guile-devel@gnu.org; Wed, 26 Mar 2014 04:25:48 -0400 Original-Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:37793 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSj9Z-0000bw-Nm for guile-devel@gnu.org; Wed, 26 Mar 2014 04:25:41 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 3CCDE119D3; Wed, 26 Mar 2014 04:25:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=Vl2cAIg8S2AxxtNKWou4q+zoJFY=; b=ubed3m 0/TsmpcAMKo7rWp3U2SGGOvFYDV0QrAWXL10t31bs1SN+lIKM60zFrRuEvfYzYnt T7QHTWbpqNmjIsngeogOy8LI2lTC5Lz/hs0KGJwQVlbXjip1sf7VfXLehuPARpu4 R+1myRpeswEkBtbZCizdqEnREODXSvdSa430w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=Mpvk/VTh5K/FIgVsUMVKnqw7mVBthZ8q gXU3DWwdYzHxWxS80m8Ogrh1SB1PNZSPmtQ2+Gu9tVB0EmF5E2Nrmp85iYHikGaG /XaeEZLNDBhvmcu7bFxV9jE8WAOWwRum8XQHzPMfbMhXoCZ9QaS7MsYNatuXFLzJ qYTVe/gHEZs= Original-Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 33397119D2; Wed, 26 Mar 2014 04:25:41 -0400 (EDT) Original-Received: from badger (unknown [88.160.190.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 62D29119D1; Wed, 26 Mar 2014 04:25:39 -0400 (EDT) In-Reply-To: <87vbv1ilzl.fsf_-_@yeeloong.lan> (Mark H. Weaver's message of "Wed, 26 Mar 2014 01:10:06 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Pobox-Relay-ID: 36AD57E2-B4C0-11E3-AA08-873F0E5B5709-02397024!a-pb-sasl-quonix.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 208.72.237.25 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:17025 Archived-At: 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? If you need more speed you can disable thread synchronization. (Admittedly there is no API for that yet, but the possibility exists, as in libc.) > 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. We can do this already. > 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, and we can disable mutexen entirely for certain ports. > 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 the case of SRFI-13-style procedures with fresh string output ports, we can avoid synchronization. For input ports, synchronization is really cheap as you don't ever have to rebuffer. In summary, I think this is a non-issue. Regards, Andy -- http://wingolog.org/