[Tinyos Core WG] TOSThreads TEP

[Vlado Handziski]

Is there a problem with posting the code to tinyos-2.x-contrib so that we
can take a look?

Vlado

On Wed, May 21, 2008 at 1:16 AM, Kevin Klues <klueska at gmail.com> wrote:

> All the #ifdefs I have are only in configurations, not in the
> implementations anywhere.  If it were up to me I would just say shadow
> everything, but some people I talked to seemed to think some
> combination of ifdefs and shadowing was better.
>
> Kevin
>
> On Tue, May 20, 2008 at 4:09 PM, Vlado Handziski
> <handzisk at tkn.tu-berlin.de> wrote:
> > On Wed, May 21, 2008 at 12:54 AM, Kevin Klues <klueska at gmail.com> wrote:
> >>
> >> More comments to come, but I wanted to address your very last one
> >> first. i.e. this one...
> >>
> >> > I for one, still believe in the basic soundness of the event-driven
> >> > model
> >> > even for user/app code. In this sense, I personally have a problem
> with
> >> > a
> >> > threading solution that is not completely optional. I don't want to
> have
> >> > a
> >> > thread scheduler being run by default. I don't want to pay a price for
> >> > wakeupThread on every interrupt. With all of those things by default
> in,
> >> > for
> >> > me this would not be TinyOS anymore.
> >>
> >> So I didn't go into the details in teh TEP, but using tosthreads and
> >> everything that comes with it would in fact be completely optional.
> >> The plan (which is is already in place and working) is to allow
> >> applications to be compiled with threading enabled by running
> >> something like the following from the command line:
> >>
> >> $ make telosb threads
> >> or
> >> $ make telosb cthreads
> >>
> >> the 'threads' target for normal nesC based applications, and
> >> 'cthreads' for c based applications.  Specifying these targets will
> >> pull in code from a 'tos/lib/tosthreads' directory and define a
> >> THREADS preprocessor variable for ifdefing any necessary code in the
> >> standard tinyos tree.  In the case of the PlatformInterruptC component
> >> described in 'tos/system' will contain a default implementation which
> >> does absolutely nothing, and the one implementing the true interrupt
> >> post amble stuff will shadow it when compiling for threads/
> >>
> >
> > I am not concerned about the binary code only. Leaving out code with
> #ifdefs
> > is not what I consider "completely optional". Apart from being ugly, just
> > having the threading code in the default components is enough to
> completely
> > confuse the users about what TinyOS really is and how they should develop
> > their applications.
> >
> > Vlado
> >
>
>
>
> --
> ~Kevin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20080521/30795e2d/attachment-0001.htm