From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200509212025.j8LKPdr29497@demeter.cs.utwente.nl> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] thread confusion In-reply-to: Your message of "Wed, 21 Sep 2005 11:42:42 -0400." References: <2e4165d0a4172357099de271ac66cd5e@lsub.org> <200509211505.j8LF5FQ00275@zamenhof.cs.utwente.nl> From: Axel Belinfante MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29493.1127334338.1@demeter.cs.utwente.nl> Date: Wed, 21 Sep 2005 22:25:38 +0200 Topicbox-Message-UUID: 8e7c7eac-ead0-11e9-9d60-3106f5b1d025 > But leave the proc alone and figure out the pipe close > bug instead. The most likely problem is that you haven't > actually closed the other side of the pipe completely. > For example, maybe you have forked a child who inherited > a copy of that fd, and that child is holding the pipe up. the problem seems to be that at both ends of the pipe a read is 'hanging'. (one from tlsClient, and one from my own pipe reader proc) If I in this situation close (both ends of) the pipe, it doesn't work. I have tried to mimic the situation in a small test program, and there I found: 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. 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. is this a correct procedure, or would another be preferred? > Programming with notes or signals is asking for trouble. I do use a timer, by having a proc that repeatedly sleeps and decrements a counter, and when the counter reaches zero it sends a (nil) timeout message on a channel. in alts I not only wait for the io channels but also for the timer timeout channel. the question is how to start and reset the timer. I have been thinking about using channels for that too, but that seems deadlock prone: how to avoid the case where I want to send a reset message to the timer when the timer wants to send an expiration message to me? could I work around that by having a timer thread in the same process with the main thread(s) that use it, and a separate clock proc (process) that does regular sleeps to generate regular tick messages? the timer thread forever does an alt to - receive timer start message (contains timer and timeout value) - receive timer reset message (contains timer) - receive tick message, triggers decrement of counters and sending of timeout message if counter reaches zero the clock proc forever sleeps and sends tick messages to the timer thread. Axel.