joel.sherrill at oarcorp.com
Mon Jun 4 16:37:15 UTC 2007
Leon Pollak wrote:
> On Monday 04 June 2007, you wrote:
>> The simple solution would be to add an attribute to
>> rtems_message_queue_create to
>> enable blocking send capabilities for the Classic API. The default
>> value should
>> correspond to the current behavior so no existing behavior is changed.
> Hmm... Tried, but this did not worked...
> I added bit to the attribute_set, raised it in 'queue_create' and changed in
> the file ../cpukit/rtems/src/msgsubmit.c line 120 from
> FALSE, /* sender does not block */
> the_message_queue->attribute_set & RTEMS_BLOCKING_SEND,
> Did not helped - still received 5 instead of blocking...:-(
The send/submit code is hard-coded to non-blocking and your
change makes it always blocking or non-blocking. Did you
actually recompile and relink the code you are running?
A timeout of zero should cause you to block forever.
Doublecheck the code against the posix blocking send code.
I don't see anything quickly in the create that would have to
be different based upon your use of the attribute bit.
We really want to support non-blocking, blocking, and
blocking with timeout sends.
The code you are trying to activate is in coremsgsubmit.c around
line 144. wait must be non-zero and you can't do a blocking send
from an ISR. Are you getting there?
FWIW I have remove the send and urgent wrappers for
msgqsubmit on the head. It seemed so wasteful when I started looking at it.
> Unfortunately, it is difficult to debug the RTEMS kernel because of
> optimization... and....Ufff...
Temporarily reduce optimization to debug your test code. Sometimes it
has to be done.
>> Or you can get me to do it. I stand on street corners with a sign that
>> says "help me -- will code for you". :)
> OK! Now I know who is this person near me on the corner! :-))
More information about the users