From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Async package.el Date: Mon, 6 Apr 2015 11:46:46 +0100 Message-ID: Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11345922b5f70905130c0336 X-Trace: ger.gmane.org 1428317225 29177 80.91.229.3 (6 Apr 2015 10:47:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Apr 2015 10:47:05 +0000 (UTC) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 06 12:47:05 2015 Return-path: Envelope-to: ged-emacs-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 1Yf4Ya-0004uW-RP for ged-emacs-devel@m.gmane.org; Mon, 06 Apr 2015 12:47:05 +0200 Original-Received: from localhost ([::1]:39430 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yf4YZ-0000kO-Um for ged-emacs-devel@m.gmane.org; Mon, 06 Apr 2015 06:47:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39608) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yf4YM-0000kI-1H for emacs-devel@gnu.org; Mon, 06 Apr 2015 06:46:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yf4YK-0007Kg-OQ for emacs-devel@gnu.org; Mon, 06 Apr 2015 06:46:49 -0400 Original-Received: from mail-lb0-x22f.google.com ([2a00:1450:4010:c04::22f]:35834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yf4YK-0007KL-Ca for emacs-devel@gnu.org; Mon, 06 Apr 2015 06:46:48 -0400 Original-Received: by lbbuc2 with SMTP id uc2so13759658lbb.2 for ; Mon, 06 Apr 2015 03:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:date:message-id:subject:from:to :content-type; bh=y1C7N9CrGKVIux51r/9OmahTwuVDwalCWkPergvC9TQ=; b=cfAAp6Cbm//oiEO/+AYcEpzCy7pYzh4kdHrhclBdE28TUe+l9NARX16Y1YIzxFXwf4 /DvMz4ts07wKbo3dMz+ar1CrEVXXt+D99HiGa2h4+9Eq8YafqjzNG1aXLgGFlbEC671M CMI9VOcrnJO4AFXkXmdZaJHJ8UwB/oChwfXDUkYxsruMQdz/VGymZHQ/U/EfkGJjvoRB qLEvDQavhVwwYxAcnz4tyY8PGjplbCyvsKuH8Qh7oKKQGPwwtab5HgxmZqoAunn9f54R yFkanPShDDV1FgslFGQSa6pU8DlDdQGDcF1mTdrkxAXEgyQzApF1i6T3a2rq4+6cKV9B lmgw== X-Received: by 10.112.83.135 with SMTP id q7mr3985266lby.13.1428317206343; Mon, 06 Apr 2015 03:46:46 -0700 (PDT) Original-Received: by 10.112.207.225 with HTTP; Mon, 6 Apr 2015 03:46:46 -0700 (PDT) X-Google-Sender-Auth: D5IHYQ5aQzLjxveVwHeCRQ_ZwS4 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185015 Archived-At: --001a11345922b5f70905130c0336 Content-Type: text/plain; charset=UTF-8 This is a heads up that I've pushed some commits that implement asynchronicity in package.el. I'll explain implementation details below, but I want to list the surface changes first. - New variable `package-menu-async'. If this is non-nil the package menu uses asynchronous operations when refreshing the archives and when installing packages. For the purpose of testing on the devlist, I've set the default to t. We can discuss whether we prefer this on or off when Emacs gets released. - For the sake of simplicity, when you hit `x' in the package-menu you will no longer get two separate prompts for install/delete. You'll be prompted a single time for everything. - If you don't use the package-menu, nothing has changed on the surface. That is, if you invoke `M-x package-install' or call this function with a single argument everything will be synchronous. But the implementation is there (determined by the function's 3rd and 4th args), so we could use the prefix arg to specify async here. Cheers to all, Artur ----- Implementation (for those who care) ----- - Most functions which involve downloading data now take an extra optional ASYNC argument (some of them also take an additional CALLBACK argument). This defaults to nil. If it is t, any downloads involved are performed asynchronously (and, if appropriate, CALLBACK is called afterwards). - The only really async function (actually a macro) is `package--with-work-buffer-async'. All other functions simply propagate their ASYNC argument down to this one. If ASYNC nil, it just defers the work back to `package--with-work-buffer'. - Archives are refreshed all at the same time (which leads to a signficant speed boost if you have several archives configured), so there's a new variable `package--downloads-in-progress' to keep track of which archive downloads are still ongoing. The function `package--update-downloads-in-progress' takes care of controling this variable and calling a relevant hook when it's all done. - Package downloads are performed in sequence, because it is generally not safe to do them in parallel (and deciding when/how it is safe is complicated). So there's no variable to keep track of them. `package-menu--perform-transaction' takes care to call `package-install' on one package at a time (and possibly calls `package-delete' afterwards). In turn, `package-install' takes care to install everything in the order specified by `package-compute-transaction' (which ensures dependencies come before the package itself). This is all done with recursive callbacks. --001a11345922b5f70905130c0336 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a heads up that I've pushed some commits = that implement asynchronicity in package.el. I'll explain implementatio= n details below, but I want to list the surface changes first.

- New variable `package-menu-async'. If this is non-nil the packa= ge menu uses asynchronous operations when refreshing the archives and when = installing packages. For the purpose of testing on the devlist, I've se= t the default to t. We can discuss whether we prefer this on or off when Em= acs gets released.

- For the sake of simplicity, when you= hit `x' in the package-menu you will no longer get two separate prompt= s for install/delete. You'll be prompted a single time for everything.<= br>
- If you don't use the package-menu, nothing has chan= ged on the surface. That is, if you invoke `M-x package-install' or cal= l this function with a single argument everything will be synchronous. But = the implementation is there (determined by the function's 3rd and 4th a= rgs), so we could use the prefix arg to specify async here.
<= br>Cheers to all,
Artur


-----
Implem= entation (for those who care)
-----

- Most functions w= hich involve downloading data now take an extra optional ASYNC argument (so= me of them also take an additional CALLBACK argument). This defaults to nil= . If it is t, any downloads involved are performed asynchronously (and, if = appropriate, CALLBACK is called afterwards).

- The only r= eally async function (actually a macro) is `package--with-work-buffer-async= '. All other functions simply propagate their ASYNC argument down to th= is one. If ASYNC nil, it just defers the work back to `package--with-work-b= uffer'.

- Archives are refreshed all at the same time= (which leads to a signficant speed boost if you have several archives conf= igured), so there's a new variable `package--downloads-in-progress'= to keep track of which archive downloads are still ongoing. The function `= package--update-downloads-in-progress' takes care of controling this va= riable and calling a relevant hook when it's all done.

- Package downloads are performed in sequence, because it is generally no= t safe to do them in parallel (and deciding when/how it is safe is complica= ted). So there's no variable to keep track of them. `package-menu--perf= orm-transaction' takes care to call `package-install' on one packag= e at a time (and possibly calls `package-delete' afterwards). In turn,= `package-install' takes care to install everything in the order specif= ied by `package-compute-transaction' (which ensures dependencies come b= efore the package itself). This is all done with recursive callbacks.
--001a11345922b5f70905130c0336--