From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 21 Sep 2005 16:37:21 -0400 From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] thread confusion In-Reply-To: <200509212025.j8LKPdr29497@demeter.cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2e4165d0a4172357099de271ac66cd5e@lsub.org> <200509211505.j8LF5FQ00275@zamenhof.cs.utwente.nl> <200509212025.j8LKPdr29497@demeter.cs.utwente.nl> Topicbox-Message-UUID: 8e852dfe-ead0-11e9-9d60-3106f5b1d025 > if I first close one randomly chosen end of the pipe, > and then do a zero-length write at the other end and > then close that end, it works. By it works I assume you mean you get a zero-length read out the other end. But that's because you did a zero-length write, not because the pipe is signaling EOF. > It also works if I first close one end of the pipe, > and then do the zero-length write and close at the > other end. Pipes are symmetric so this is good. > is this a correct procedure, or would another be preferred? What doesn't work? Can you post a small test program that doesn't make a blocked read fail when the other end of the pipe is closed? Again, it sounds like you're not closing all the references to one end of the pipe. If multiple programs have references to a pipe end, they *all* need to close them. Make sure that the proc running tlsClient doesn't have a reference too. > the question is how to start and reset the timer. It depends how granular this timer is. If we're talking about something large like seconds, then it is reasonable to have the timer proc just poll the channel with nbrecvp for new work or cancellations after it ticks off each second. Your alternate approach, with a tick stream, is also reasonable. No matter which you use, the return channels that the timer proc writes to should be buffered so that the timer proc never blocks writing to them. Russ