On 2010-05-10 17:18, Mathieu Bouchard wrote:
>
> one is [iemguts/oreceive]. what's the other one ?
[gemreceive], which is a clone of the above.
>
> and why "don't try to hunt them down" ?
>
because most likely there are better/more portable ways to fix the
original problem.
this reminds me o
On Mon, 10 May 2010, IOhannes m zmoelnig wrote:
PS: rumours are that there are at least two different receive objects
living out there that have a way to define explicit ordering. don't try
to hunt them down
one is [iemguts/oreceive]. what's the other one ?
and why "don't try to hunt them dow
On 2010-05-10 07:34, Alexandre Porres wrote:
> hi there, quick question,
>
> say I got a [send] object and many pairing [receive]... how do you predict
> the ordering of messages, or can't you do it at all? Meaning, which receive
> will actually receive the data first? The one that was first conne
> Meaning, which receive will actually receive the data first? The one that
> was first connected?
>
Althougth that is true for local connections, weirdly enough, in non-local
connections the last created receive object receives data first.
In local connections the problem can be solved using trig
hi there, quick question,
say I got a [send] object and many pairing [receive]... how do you predict
the ordering of messages, or can't you do it at all? Meaning, which receive
will actually receive the data first? The one that was first connected?
My hint is that you have no way to control this
