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 / 277
  Re: signals / legOS internals
 
(...) I should add that since many things are vectored in this version of Librcx, overriding functionality is easy for the advanced user to do. For example: extern void (*__event_vector)(void); void my_setup_func() { // ... __event_vector = (...) (25 years ago, 24-Jun-99, to lugnet.robotics.rcx.legos)
 
  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)
 
  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)
 
  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)
 
  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)
 
  Re: signals / legOS internals
 
(...) Now keep in mind that this is coming from someone who won't take Duke's OS class until next spring- is there any reason the current semaphore implementation couldn't be used for a large percentage of these tasks? I.E., thread A checks (or uses (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
 
  Re: signals / legOS internals
 
(...) Yes, that is it. A classic example is a full screen app such as vi. When being stopped, vi sets the terminal mode to something generic and saves any screen info that it needs. When resumed, it sets the terminal mode back to what it wants and (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
 
  Re: signals / legOS internals
 
(...) They could. In fact, there may be cases where that is exactly what you want to do. However, that requires you to write your code to examine the semaphore at every point where you would want to consider processing the event. It is more work. (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
 
  Re: signals / legOS internals
 
(...) So is the idea that you might have a "shell" app that lets you control a button or two and that takes over the lcd at times (say), and lets you start, suspend, and stop other apps that control different, presumably disjoint sets of motors and (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)

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