From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Thu, 7 Dec 2006 16:37:22 -0500 From: "Russ Cox" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] OT: cannonical set of queue ops In-Reply-To: <15215407ef3dbfddfed3946505e2dc78@quintile.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <15215407ef3dbfddfed3946505e2dc78@quintile.net> Topicbox-Message-UUID: ec3ab8aa-ead1-11e9-9d60-3106f5b1d025 I have had a similar problem in some applications I have written using venti. As Richard Bilson points out, the tempting solution is not the best one. I think that you want to have an explicit "no more sending will happen" state, the same as a pipe where one end has been closed. Then the receiving end can get the "EOF" once it has read the remaining items and can close its side. Once both sides are closed, the queue is freed. There are various ways you could frame things (for example, you could require that the write side is always closed before the read side), but no matter what you always end up with a two-step: first the writer signals he is done (could write an empty message instead), then the reader cleans up when he sees he has gotten everything. Can hide in a library or handle explicitly. One reason that having an IsQueueEmpty complicates things is that allowing the *writer* to check whether the *reader* has gotten all the messages yet causes information to flow backward (from reader to writer). Russ