World: r3wp

hehe sometimes more is less  ;-)

Maybe make benchmarks first. Blast a realistic amount of data from 
rebol to rebol. Maybe by beer or uniserve, something fast.

I am not sure it is true anymore, but we noticed it developing our 
ccd camera few years ago ... OS simply waits with ACK defined period 
of time or simply to receive second packet, then it confirm both 
.... Ethereal will give you an answer :-)

Pekr, good hint. But i guess to calls to send a byte are two packets 
too. And then there was some flag too IIRC. Somebody remember?

yes, isn't it called Nagle algorithm? It can be set - nodelay ...

in set-modes I mean ....

but is not recommended IIRC :-)

Gabriele, tasking without any explicit control  is risky. How do 
you handle two task both writting to the same file, who gets access 
to the resource, how you enforce determinism?

Apple closes down OS-X - http://www.infoworld.com/article/06/05/17/78300_21OPcurve_1.html

have not read it yet, so sorry if it is not what topic states ....

Tasking discussion could move to Rebol3 maybe? (because there is 
general interest in the concept)

Closes the source of os-x

darvin-kernel.

Jaime, writing to files is something for the os to handle, not the 
language. what happens if you write from rebol on a file you're writing 
from another app?

Maybe Jaime means: If you do everything that way, including the os? 
But, there would be no  such thing as a file, there would be a file-server, 
eg a third task. Which gets request and can sort them out.

pekr, because of piracy??

Gabriele, I don't think is an OS issue only. Once you introduce tasking 
would could write something like:

do [
    task [write %file "Hello"]
    task [write %file "World"]
]


The question is what is the result of such computation. Without any 
further mechanism it can produce as minimum two different results. 
"World Hello"  "Hello World", discarding posible contention errors. 
So how does R3 will manage such issues.

Creative sues Apple over patents - http://www.marketwatch.com/News/Story/Story.aspx?dist=newsfinder&siteid=google&guid=%7BCB4F9BED-E370-4CCA-92E6-AC8EB26451F4%7D&keyword=

what a crap - I stop buying Creative stuff. If some company can't 
innovate, they should shut-up and leave the scene. How can anyone 
with good brain condition patent such a thing as sorting based upon 
ID3 tag content?

One can even sue about using a trashcan -icon for a trashcan IIRC..

do[

  task 'task-server [ set[file content] copy msg  write file content 
  ]
  task [ send 'task-server %file "Hello" ]
  task[ send 'task-server %file "World" ]
]

'task-server -> 'file-server

Volker, you are proposing data flow through msg queues?

But the msg queue above still has non-determinism involved. Because 
you can not control how TASK handles scheduling.

Why get so excited ? Did you read the last line in that article ?

But what you wrote is similar too
either 1 = random 2[ write%file "Hello"][write %file "world"]

What a task does depends upon what a task gets. I imagine a task 
in erlang as a little engine, which gets things of various kinds, 
wires them together when it has one of each kind and passes them 
further. And that "further" can not be deterministic with real hardware. 
Think of an out-of-order-cpu, a little delay in a memory-fetch and 
the command is processed by another pipeline. And that is without 
routing around crashed things. I prefer to have a full featured language 
to calculate the new route, not something restricted.

Jaime, I just don't think rebol should manage files. but, you can 
do coordination, just using message ports. and you can write a dialect 
over that.

the real issue is: people always use multithreading, even when there 
is no reason to.

if a thread has to wait for another, then you're just wasting time 
and creating problems with threads.

threads are efficient when they are independent (tasks). otherwise 
you should not use them.

if you want order, don't make two separate tasks. if you make two 
separate tasks is because you don't want order.

Gabriele - so we will ge threads, which will be simplified for rebol 
users/coders, and some kind of messsage queues?

But IMO Jaime thought he needs sometimes exclusive access, locking. 
After my example he got it mostly, "Volker, you are proposing data 
flow through msg queues?".

locking is painful, a server like you propose is much better.

Now we discuss how to put enough determinism in that system.

i need to read that paper jaime posted; anyway if it's just linda 
style, it's trivial to do with a server handling the tuple space.

i think that if you want determinism you should probably avoid parallel 
processing. parallel processing is good when you don't care about 
determinism - if you care then where is the advantage?

Prepending i understood it and ask for theothers: What isa tuple-space? 
:)

volker: basically a block of blocks :)

you cannot address the block; you can only get the blocks matching 
a pattern, and publish other blocks.

having a defined set of operations, you end up with a system that 
does not have the usual problems of parallel processing.

i don't think there's any need to have this natively, the native 
code just needs to ensure that you cannot screw things up by mistake 
:)

Maybe determinism means here: Some things must happen in order, for 
example writing to a log? So that different runs produce the same 
result?

Which this server-thing should do.

if you want to log events a and b, and they can happen with watever 
order, you want to log them in whatever order. if they can only happen 
in a given order, there is no parallelism.

Just thinking loud about tuple-space: Could xpath and threads go 
hand in hand?

But a parralel processed image looks the same all the time, or the 
processing of a big matrix. Still deterministic. Whatever happens 
inside the box.

Sun blesses Java phone - http://www.deviceforge.com/news/NS6109398413.html
.... java penetration is the reason why I asked if rebol-4-Java would 
make sense :-)

Anton, Yes I read the last line and I agree with it. The question 
is what should Rebol do to takle the concept of concurrency and do 
it properly, like Erlang, Termite, or Mozart/Oz.

Volker, I was ilustrating that just using the function TASK is not 
enough. You need a way to prune non-determinism. The example I posted 
ilustrate the problem. Your example has the same problem than mine, 
because TASK it doesn't introduce an order of execution. The fact 
that your example is coded sequentially doesn't mean that the computation 
will be carried in that order and produce the same result always. 
Your example only introduces notatation to pass messages between 
tasks.