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: thoughts on ports Date: Sun, 08 Apr 2012 13:21:24 -0700 Message-ID: <87zkam7z5n.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1333996133 26484 80.91.229.3 (9 Apr 2012 18:28:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 9 Apr 2012 18:28:53 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Apr 09 20:28:52 2012 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 1SHJKa-0004MC-LE for guile-devel@m.gmane.org; Mon, 09 Apr 2012 20:28:48 +0200 Original-Received: from localhost ([::1]:36198 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SHJKZ-0004OS-QW for guile-devel@m.gmane.org; Mon, 09 Apr 2012 14:28:47 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52400) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SHJKU-00048u-Qv for guile-devel@gnu.org; Mon, 09 Apr 2012 14:28:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SHJKS-0005EF-Ui for guile-devel@gnu.org; Mon, 09 Apr 2012 14:28:42 -0400 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:36056 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SHJKS-0005DY-Ls for guile-devel@gnu.org; Mon, 09 Apr 2012 14:28:40 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id AD2699F3D for ; Mon, 9 Apr 2012 14:28:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:date:message-id:mime-version:content-type; s=sasl; bh=5 lProdmBVzrduS32Cc/UAMwkpsw=; b=Oza12uoteHLaRS8RWTONboJMeo6XDgZdY SUW/keBRbqQlinrTss+8Ma1Caw4Jj2uDZat6sPSbnkRc/AlpbuPw51N1KKUzdOdp yxEjUBjlfrbHZcWwJcErXUTA1Q2UUykCdDU864lh3VftGDMKSPcrDZZvhM2ZgPAp mzZ0OmOBSE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject :date:message-id:mime-version:content-type; q=dns; s=sasl; b=YrG 2JGIWwJQ9tZf+a/o4xwIlo9HcNnslOufcXw5bvK348xfwBE/txayPV1I0VUn0dwr URdK6uF5e7i6FKtGyQtkEMW6w2vjkcEEkyi/SafgumeFliUggJMH5FENMFXdYims F4W0f7OrlC9mVW9L/DrL8NaaCLo0QOx/7fotVCnU= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 95ED29F33 for ; Mon, 9 Apr 2012 14:28:35 -0400 (EDT) Original-Received: from badger (unknown [173.8.133.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id C883A9F32 for ; Mon, 9 Apr 2012 14:28:30 -0400 (EDT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) X-Pobox-Relay-ID: D093C39C-8271-11E1-B91F-B1B0728A0A4D-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 74.115.168.62 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:14231 Archived-At: Hi all, I have been thinking about ports recently. I know other folks have had some thoughts here too, so it's probably good to have a discussion about how they should look. I'm coming from the perspective of the recent (ice-9 eports) work on wip-ethreads. I found that it's fun and useful to be able to implement ports in Scheme. Fun, because it's Scheme; and useful, because you can block via saving the (composable) continuation, adding to a poll loop, and rescheduling. There are also some potential optimizations when you implement ports things in Scheme because for most users, who program in Scheme, you cut out some layers. It turns out that (ice-9 eports) don't actually have anything to do with events, in the end -- having added a simple abstraction for read/write/close operations, there is no fd-specific code in the eports stuff. Eports are more about efficiently and flexibly handling binary input and output, with appropriate buffering. That starts to raise the question of what the relationship of (ice-9 eports) is with our ports implemented in C (let's call them "cports"), and the panoply of interfaces implemented for cports. Obviously we need ports implemented in C because of bootstrapping concerns. But can we give Scheme access to buffering and the underlying fill (read) / drain (write) / wait (select) operations? So, the idea: refactor the port buffers (read, write, putback) to be Scheme bytevectors, and internally store offsets instead of pointers. Give access to some internal port primitives to a new (ice-9 ports) module. I think we can manage to make (ice-9 ports) operate in both binary and textual modes without a problem, just as we do with cports. We'll have to expose some iconv primitives to (ice-9 ports), but that's just as well. (Perhaps we should supply an (ice-9 iconv) module ?) This is also our chance to modularize the ports code. We can add module autoloads to load up less-frequently-used parts of the ports interface on demand. Anyway, that's my current thought. Again, the advantages: fewer layers between Scheme and I/O, modularization, and the ability to suspend blocking operations in user-space rather than kernel-space. Thoughts? Cheers, Andy -- http://wingolog.org/