To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.legosOpen lugnet.robotics.rcx.legos in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / legOS / 282
281  |  283
Subject: 
Re: signals / legOS internals
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Sat, 26 Jun 1999 06:54:16 GMT
Viewed: 
1264 times
  
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.

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.

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.

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.

-Kekoa



Message has 1 Reply:
  Re: signals / legOS internals
 
(...) Cool. I will proceed. (...) Yup. I was out of the loop for awhile, and am once again whompin' on this project. (...) That is true. Signals would give the task the opportunity to stop/start tasks under its control, though, without the task that (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)

Message is in Reply To:
  Re: signals / legOS internals
 
(...) 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. I think one of the original reasons for (...) (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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR