Subject:
|
Re: signals / legOS internals
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Sat, 26 Jun 1999 16:44:34 GMT
|
Viewed:
|
1224 times
|
| |
|
|
Kekoa Proudfoot wrote:
>
> Lou Sortman <theball@bigfoot.com> wrote:
> > So, should I abandon my implementation? If something every bit as good
> > is already there, it may be silly for me to continue. I haven't looked
> > at Librcx yet, so I don't completely understand how it works.
>
> No, you should not abandon your implementation - not if you want to use
> LegOS. I was only explaining how I implemented similar functionality, for
> the sake of comparison.
Cool. I will proceed.
> Regarding Librcx, I might release another version at some point, to add
> more-generalized non-ROM support for all types of i/o, but who knows when
> that will happen. I have been playing around with other things lately, and
> have not been spending too much time with my RCX.
Yup. I was out of the loop for awhile, and am once again whompin' on
this project.
>
> > I think one of the original reasons for implementing signals may have
> > been to suspend and resume tasks.
>
> That is a reasonable, per-thread thing that I had not thought of using
> signals for and that my signal-like implementation does not handle.
>
> But why do you need signals to do that? If you are a thread, and you have
> a reference to another thread (pid, pointer to thread data structure,
> whatever), then there should be functions for you to manipulate the thread
> you have a pointer to, including suspending and resuming that thread.
That is true. Signals would give the task the opportunity to stop/start
tasks under its control, though, without the task that makes the calls
having to know about that relationship. That could be done through
dedicated callbacks in the process structure, but by that point, you've
almost got signals anyway.
>
> Or maybe signals are a nicer way of doing this in some cases I haven't
> thought of?
>
> > > Actually, I bet this is slightly different from the signal mechanism being
> > > discussed, which probably has one vector per thread/process. Librcx only
> > > has a single, global set of vectors.
> >
> > Ok, I know I'm being dense, but what are the implications of this?
>
> If there is only one vector that gets called when a specific event occurs
> (say, a button is pressed), then only one thread can hook into that vector.
> Therefore, you might way that the vectors are not very thread-friendly.
> But they are not supposed to be. The vectors are meant to be very
> low-level hooks, internal to the library but there if you want to modify
> them. The default thing hooked into a vector (if anything is hooked into
> the vector) is supposed to be some other part of the library, something
> that provides higher level event notification to any number of threads.
That is the way I'd do it anyway. Have a thread whose sole job it is to
manage a resource and communicate with any interested threads. This is
how I implemented motor ramping.
With the vectored approach, it may not necessarily need to be a thread.
|
|
Message has 1 Reply:
 | | Re: signals / legOS internals
|
| (...) What am I missing? Why do you need callbacks in the process structure? I was thinking if you can reference the thread, you can just call a system function (e.g. suspend(thread)), and that will suspend the thread. You do not need callbacks (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: signals / legOS internals
|
| (...) No, you should not abandon your implementation - not if you want to use LegOS. I was only explaining how I implemented similar functionality, for the sake of comparison. Regarding Librcx, I might release another version at some point, to add (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
32 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
