> On 04/12/2011 11:58 PM, t [dot] j [dot] a [dot] devries [..] ... wrote:
>> See subject.
>
> if (Port.size() == Port.capacity()) {//Port is full
> }
>
> I personally use a while (!Port.empty()){} when reading from my buffer
> ports.
I doubt whether these methods are "thread safe"... It is, in my opinion,
better to have an atomic interaction with a Port (i.e., read the whole
information it has in one, thread-safe go), and then examine the status and
take decisions in the safe context of one's own thread, and with full
ownership of this data.
On Wednesday 13 April 2011 12:33:49 Sagar Behere wrote:
> On 04/12/2011 11:58 PM, t [dot] j [dot] a [dot] devries [..] ... wrote:
> > See subject.
>
> if (Port.size() == Port.capacity()) {//Port is full
> }
>
> I personally use a while (!Port.empty()){} when reading from my buffer
> ports.
>
Such API is no longer available in 2.x. There is no distinction between 'data'
ports and'buffer' ports. There's only input and output ports. The connection
between the ports will determine if buffering is going on or not.
On Tuesday 12 April 2011 23:58:41 t [dot] j [dot] a [dot] devries [..] ... wrote:
> See subject.
>
> Theo
You can't know, because the connection policy is abstract. You don't even know
if there is buffering going on. We made this descision to force a level of re-
usability on the components. Implementations that assume all kinds of
connection policies are not re-usable/combinable with components that assume
other kinds.
how to test if an InputPort with a Buffer policy is full?
On 04/12/2011 11:58 PM, t [dot] j [dot] a [dot] devries [..] ... wrote:
> See subject.
if (Port.size() == Port.capacity()) {//Port is full
}
I personally use a while (!Port.empty()){} when reading from my buffer
ports.
/Sagar
how to test if an InputPort with a Buffer policy is full?
On Wed, 13 Apr 2011, Sagar Behere wrote:
> On 04/12/2011 11:58 PM, t [dot] j [dot] a [dot] devries [..] ... wrote:
>> See subject.
>
> if (Port.size() == Port.capacity()) {//Port is full
> }
>
> I personally use a while (!Port.empty()){} when reading from my buffer
> ports.
I doubt whether these methods are "thread safe"... It is, in my opinion,
better to have an atomic interaction with a Port (i.e., read the whole
information it has in one, thread-safe go), and then examine the status and
take decisions in the safe context of one's own thread, and with full
ownership of this data.
Herman
how to test if an InputPort with a Buffer policy is full?
On Wednesday 13 April 2011 12:33:49 Sagar Behere wrote:
> On 04/12/2011 11:58 PM, t [dot] j [dot] a [dot] devries [..] ... wrote:
> > See subject.
>
> if (Port.size() == Port.capacity()) {//Port is full
> }
>
> I personally use a while (!Port.empty()){} when reading from my buffer
> ports.
>
Such API is no longer available in 2.x. There is no distinction between 'data'
ports and'buffer' ports. There's only input and output ports. The connection
between the ports will determine if buffering is going on or not.
Peter
how to test if an InputPort with a Buffer policy is full?
On Tuesday 12 April 2011 23:58:41 t [dot] j [dot] a [dot] devries [..] ... wrote:
> See subject.
>
> Theo
You can't know, because the connection policy is abstract. You don't even know
if there is buffering going on. We made this descision to force a level of re-
usability on the components. Implementations that assume all kinds of
connection policies are not re-usable/combinable with components that assume
other kinds.
Peter