[Phoenix-pm] From P5P, mostly for Brock: Coro(utine) support from the perl core

[Scott Walters]

----- Forwarded message from Marc Lehmann <schmorp at schmorp.de> -----

Return-Path: perl5-porters-return-110505-scott=slowass.net at perl.org
X-Original-To: scott at slowass.net
Delivered-To: scott at slowass.net
Received: from lists.develooper.com (x6.develooper.com [63.251.223.186])
	by slowass.net (Postfix) with SMTP id C7885553AA
	for <scott at slowass.net>; Thu,  9 Mar 2006 08:35:16 +0000 (GMT)
Received: (qmail 5463 invoked by uid 514); 9 Mar 2006 08:28:16 -0000
Mailing-List: contact perl5-porters-help at perl.org; run by ezmlm
Precedence: bulk
list-help: <mailto:perl5-porters-help at perl.org>
list-unsubscribe: <mailto:perl5-porters-unsubscribe at perl.org>
list-post: <mailto:perl5-porters at perl.org>
X-List-Archive: <http://nntp.perl.org/group/perl.perl5.porters/110505>
List-Id: <perl5-porters.perl.org>
Delivered-To: mailing list perl5-porters at perl.org
Delivered-To: moderator for perl5-porters at perl.org
Received: (qmail 24465 invoked from network); 9 Mar 2006 01:07:36 -0000
Delivered-To: perl5-porters at perl.org
X-Spam-Status: No, hits=-2.6 required=8.0
	tests=BAYES_00,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: la.mx.develooper.com
Received-SPF: pass (x1.develooper.com: domain of root at schmorp.de designates 193.108.181.162 as permitted sender)
Date: Thu, 9 Mar 2006 02:07:16 +0100
From: Marc Lehmann <schmorp at schmorp.de>
To: perl5-porters at perl.org
Subject: Coro(utine) support from the perl core
Message-ID: <20060309010716.GA13267 at schmorp.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-PGP: "1024D/DA743396 1999-01-26 Marc Alexander Lehmann <schmorp at schmorp.de>
       Key fingerprint = 475A FE9B D1D4 039E 01AC  C217 A1E8 0270 DA74 3396"

[If possible, please send a courtesy CC directly to me when replying]

Hi!

On the german perl workshop, I shortly discussed with Nicholas Clark what
kind of support the Coro module would need from the perl core to work
better.

While I admit that I wasn't active on p5p for a long time, nor am I even
using 5.9, I think a few things would indeed be helpful. However, the Coro
module works surprisingly well (with minimal changes between 5.6 and 5.8
for example, only 5.9 might make some problems).

In any case, here is a list of things that I do that might benefit from
better core support. If you want to know what I am talking about, all
relevant code is in Coro-xxx/Coro/State.xs.

- the load_state/save_state functions are the core of the module, they simply
  save and restore most perl "globals". From time to time, another global
  that I forgot comes up, so it might help to know which globals should be
  saved/restored and which don't need to, or shouldn't.

  It works well enough at the moment, but some standard mechanism for
  swapping the state might help.

- the Coro module has to walk up the whole call chain to "undo" function
  calls, mostly due to the padlists. I keep an array of "fresh" padlists
  attached to each CV using magic.

  Here's the creepy fact: clone_padlist is used to create a new "initial"
  padlist. I think the "fake threads", whatever they are supposed to be,
  also need a similar but not identical function, and the code is copied
  from a function within perl (S_cv_clone2) almost verbatim, except for
  the case thats been commented out with ENOTUNDERSTOOD, because I have
  no idea what it does, or what its for. And I have stripped it down
  considerably.

  What would help would be a core-supported clone_padlist function, or
  similar functionality, so I wouldn't have to mess with CV internals that
  much.

  Also, it would be nice if this padlist cloning wouldn't be necessary,
  and/or the call walk wouldn't be neecssary, but most call chains are
  shallow, so this isn't a big performance problem in practise.

- The callchain walking works by walking up the cxstacks. I am not sure
  when multiple cx stacks are in use, or wether I have to walk all of them
  or ... I simply have no idea.

  I also ignore CXt_FORMAT. Never saw them never used them. Probably its ok
  to ignore them anyways. Some comment on that would be helpful :)

- When creating a new coroutine, I have to initialise the stacks, which is
  done with coro_init_stacks. This is another almost verbatim copy of the
  similar fucntion inside the perl core (Perl_init_stacks), except that
  it allocates much less intiial stack space, in the assumption that most
  coroutines will not use that much perl stack.

  It would be nice if there were a function in the perl core that I could
  call instead.

- Similar "destroy_stacks", which I need when destroying a subroutine. The
  code is rather weird: I LEAVE_SCOPE(0), FREETMPS, and when I
  POPSTACK_TO(PL_mainstack), I get weird errors and segfaults, so I don't do
  the latter. Again, I don't understand anything about what I am doing there,
  and having this correctly done inside the perl core would help again.

- in "continue_coro", I basically create a simple perl interpreter. I am not
  sure wether I set up the PL_top_env correctly. Just in case, all new
  coroutines have a top-level eval {} that catches runtime errors.

Thats all I could come up with with potential issues where the perl core
could help. Any feedback would be appreciated.

-- 
                The choice of a
      -----==-     _GNU_
      ----==-- _       generation     Marc Lehmann
      ---==---(_)__  __ ____  __      pcg at goof.com
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE
----- End forwarded message -----