Re: Non blocking flush semantics.

Shabtay,

Shabtay Matalon wrote:
> Hi John,
> 
>  
> 
> Non blocking flush() semantics is an orthogonal issue to the current 
> pipes proposals. Can you address my question bellow by email?

johnS:
Sure. See below ...


>  
> 
> Re: 1.5
> 
>    - You asked why c_try_flush() is needed. This is to provide
> 
>      a thread neutral call for the benefit of the blocking c_flush()
> 
>      to be implemented over a specific threading system
> 
>      just as c_try_send() is the thread neutral assist call for
> 
>      the benefit of the blocking c_send() call.
> 
> */[Shabtay] Our reservation to c_try_flush() was that flush should 
> always be implicitly successful. Which conditions should cause the to 
> c_try_flush() function to return with failed or success status?/*

johnS:

No, c_try_flush() is not always implicitly successful.

The blocking c_flush() is always implicitly successful.

The whole purpose of non-blocking calls in general is to test
for success within a blocking function and not return if
the success is not there.

The easiest way to look at flush is to look at send.

A blocking send is always implicitly successful. It can be
implemented (as you see in examples in the reference models and spec.)
over a loop of non-blocking sends that are not always implicitly
successful.

Flush works in exactly the same way.

The non-blocking flush is probably something users should
never use. It is mainly there to complete the thread-neutral
API that provides full functionality for implementation of
higher level thread-aware API calls that are blocking.

If you look at section 4.9.1.1 of the last version of the
spec that I sent out you'll see the sample
implementations of blocking send and blocking flush
that should make this more clear.

I would actually not mind getting rid of the try_flush()
call if we could think of a better way of modifying
the thread-neutral interface to provide the necessary
hooks to implement a thread-aware blocking flush.

I've added the explanation above to the next revision of
the working document for the pipes piece.

-- johnS
<eom>

> 
>  
> 
>  
> 
> Re: 1.7
> 
>     - Some good comments on flush semantics - those have been added to the
> 
>       latest document spec. revision 1.12.
> 
>  
> 
> */[Shabtay] Great. But we need to settle try_flush semantics./*
> 
> -- johnS
> 
>  
> 


-- 

This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________