Message_queue_Submit function

[Joel Sherrill]

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 */
> to
> 	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! :-))
>
>
>   
:)

>> --joel
>>     
> Leon.
>