Subject:
|
Re: LegOS 0.2.5 and LNP
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Mon, 22 Jan 2001 23:58:25 GMT
|
Viewed:
|
1323 times
|
| |
|
|
> It's not for performance, but for correctness. The old code • was like this:
>
> if(lnp_addressing_handler[port]) {
> ...
> lnp_addressing_handler[port](data,length-2,src);
>
> You first test lnp_integrity_handler and then, before using it, • you reload
> it from memory. If the value has changed (and it could on a • PC, as you are
> not in an interrupt handler) you have problems. The right • thing is to read
> once and use twice. Probably if there are no function calls in • place of
> "..." (but in 0.2.5 there may be one) the compiler will • optimize it and
> read only once, but it's better to force the compiler to do • what you want
> with actual code. For the same reason I added the volatile
attribute.
Yes, but I'm not sure what could happen if I change those
addresses in the middle of the execution, and the old handler
code is gone...
I think that the handler code function initializer
(lnp_*_set_handler) instead should be sure that handler functions
addresses are written with Interrupt disabled or a sort of. Is it
needed a sem_lnp_address too?
Have you found some evidence or examples of someone that could
change those handlers without causing some "logical" crash in the
program? I mean that this type of behavier is quite undesiderable
in a program doesn't it? I'm quite sure that if someone change
those handlers without passing from LNP_DUMMY_ADDRESSING (in a
sort of logical pause in processing LNP packets) could have some
other problems... We could check against it before assigning the
new handler...
What about a new version of:
lnp_integrity_set_handler(lnp_integrity_handler_t handler)
and
lnp_addressing_set_handler(unsigned char port,
lnp_addressing_handler_t handler)
that returns an error and do not change handlers if the handler
is not null?
BTW: In meantime I'll also modify:
lnp_integrity_state_t lnp_integrity_state;
in
volatile lnp_integrity_state_t lnp_integrity_state;
for correctness too... Any feedback?
Bye,
Paolo.
---
"Is there something I can do for you, Captain?" - Spock
|
|
Message has 1 Reply:
 | | Re: LegOS 0.2.5 and LNP
|
| (...) On the RCX the LNP handlers are called from an interrupt handler, so after the execution of lnp_*_set_handler() you can safely assume that the old handler will not be called any more. On a PC things are different, there is a problem. I didn't (...) (24 years ago, 23-Jan-01, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: LegOS 0.2.5 and LNP
|
| (...) Ok. Checking and testing never hurts :-). (...) It's not for performance, but for correctness. The old code was like this: if(lnp_addressing_ha...ler[port]) { ... lnp_addressing_handl...th-2,src); You first test lnp_integrity_handler and then, (...) (24 years ago, 21-Jan-01, to lugnet.robotics.rcx.legos)
|
9 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
|
|
|
|
