Non blocking flush semantics.

Hi John, 

 

Non blocking flush() semantics is an orthogonal issue to the current
pipes proposals. Can you address my question bellow by email?

 

Brain,

 

Do we have an IM for this? This is different than IM226. If not, please
add one.

 

Shabtay 

 

 

________________________________

From: owner-itc@verilog.org [mailto:owner-itc@verilog.org] On Behalf Of
Shabtay Matalon
Sent: Wednesday, June 07, 2006 3:57 PM
To: John Stickley; itc@verilog.org
Subject: RE: detailed feedback on object pipes proposal

 

Hi John,

 

Please review my responses to your email.

 

Shabtay

 

-----Original Message-----
From: owner-itc@verilog.org [mailto:owner-itc@verilog.org] On Behalf Of
John Stickley
Sent: Tuesday, June 06, 2006 8:31 AM
To: itc@verilog.org
Subject: detailed feedback on object pipes proposal

 

 

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?

 

 

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