> 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.
