From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] thread confusion
Date: Tue, 27 Sep 2005 12:12:54 +0200 [thread overview]
Message-ID: <200509271012.j8RACsT11583@zamenhof.cs.utwente.nl> (raw)
In-Reply-To: Your message of "Mon, 26 Sep 2005 19:40:44 +0100." <e38ad92517d2aad998df759d7d213c1a@vitanuova.com>
> > 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?
>
> i think this is a good question.
>
> i've found writing time-based code using the threads library to be
> quite awkward. it seems to me that there may be room for an extension
> to help with writing this kind of code.
>
> the difficulty with the plan 9 thread library (and with Limbo too) is
> that sleep(2) exists in a different universe to channels, so one has
> to use a separate process to bridge the gap.
>
> but when this thread is sleeping, it's not possible to communicate
> with it, so one needs another thread to act as an intermediary, and
> one has to design the interface carefully - if possible one doesn't
> want a separate process and thread for each thread that wishes to wait
> for a little while.
I have seen the followup discussion after this post and like
the idea of support for this in the thread library.
Indeed the accuracy may/will be higher than what I'm using
right now (but for my use it is not really an issue, I guess).
This is just to share the approach I have taken after
my initial posts on the topic.
(after some bad experience) I've abandoned the idea
of a timer process that only delivers expiration messages,
and with which one communicates to start and cancel timers.
Instead I'm using (something like) the etimer(2) approach.
I have now a proc that regularly sends ticks over a channel
using non-blocking sends, and decrement timers and check
for expiration in the alt.
Hmm... thinking on it while writing this, I suppose
that tickproc could just as well use blocking sends.
void
tickproc(void *v)
{
for(;;) {
sleep(tickTime);
nbsend((Channel*)v, nil);
}
}
use of ticks:
...
t = ticksToWait;
done = 0;
while(!done)
switch(alt(a)){
case iochannel:
done = 1;
... other handling ...
break;
...
case tickchannel:
t--;
if (t == 0) {
done = 1;
... handle timeout ...
}
}
...
This seems to get the job done in
a less complex and more clean way
than what I was using before.
Axel.
next prev parent reply other threads:[~2005-09-27 10:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-21 14:44 Fco. J. Ballesteros
2005-09-21 15:05 ` Axel Belinfante
2005-09-21 15:42 ` Russ Cox
2005-09-21 20:25 ` Axel Belinfante
2005-09-21 20:32 ` Axel Belinfante
2005-09-21 20:37 ` Russ Cox
2005-09-21 22:34 ` Axel Belinfante
2005-09-21 22:44 ` Russ Cox
2005-09-26 18:40 ` rog
2005-09-26 18:52 ` Russ Cox
2005-09-26 19:20 ` rog
2005-09-27 10:12 ` Axel Belinfante [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-09-21 15:48 Fco. J. Ballesteros
2005-09-21 13:53 Fco. J. Ballesteros
2005-09-21 14:32 ` Axel Belinfante
2005-09-21 13:25 Axel Belinfante
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200509271012.j8RACsT11583@zamenhof.cs.utwente.nl \
--to=axel.belinfante@cs.utwente.nl \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).