From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <d555a1ae7e1735204d7ee20381034260@terzarima.net>
From: Charles Forsyth <forsyth@terzarima.net>
Date: Thu, 28 Oct 2010 13:12:36 +0100
To: 9fans@9fans.net
In-Reply-To: <AANLkTinEZZu-8qKfh6u3qdcJbcE6M_=eQjqBxP_2PkCG@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] A little more ado about async Tclunk
Topicbox-Message-UUID: 7011b74c-ead6-11e9-9d60-3106f5b1d025

you're essentially replacing
	f := open(name, ...)
	...
	close(f)

which runs as a sequential process, and subject to the usual rules for sequential
composition, by

	f := open(name, ...)
	...
	spawn clunk(f)

which introduces a race with an invisible anonymous process with no means of synchronisation.

what could possibly go wrong with that?

(actually, it's more complex than spawning a new process, but the added complexity of a set of service processes changes the details but not the existence of the race, and doesn't affect the anonymity.)

the change isn't sufficent to solve the efficiency (latency) problems addressed by Op,
neither is it sufficient for big performance improvements if you're dealing with something you can cache,
nor is it a necessary solution (at least in the form above) for the deadlock problems.