World: r3wp

but it's sayed futher that the buffer is not recreated each time 
a read occurs

Check IO-Request connection flag. This is not a socket check, it 
is a request state flag check.
Check the port/data for an existing buffer.

If no buffer found, allocate one that is of the default size (32,000). 
Note: not 32K.
Compute buffer space available.

If available space is less than half the default size, extend the 
buffer.
Recompute buffer space available.

Setup the IO-request data and length fields. Data is the buffer tail 
position. Length is the buffer space available from above. Clear 
the actual field.
Call the TCP device with READ command.
Check result for error. If error, throw it.

so i think i got it.

it is saying it is recreated itf it does not exist

eg. after a tcp write

if there is sequential tcp read .. it does not recreate

seems a lot of gc must be happening at the tcp port

i wonder if the doc is up to date

I guess Carl has his reasons on doing it this way instead of having 
separate buffers for read and write

Have you fixed my ftp scheme so that it works properly yet?

who me ? I never say that

LOL ...

needs a lot of work ... :(

read/write buffers are shared?

yes

seems to be according to the docs you linked to

i should make a try, i have some doubts

what is it good for? That way you have to read-out all data from 
buffer first, before you do "reverse" (read/write) operation, or 
you mess the data, no?

yes, copy all your data first before doing a write

store it in port/locals somewhere

it sounds to me as an unnecessary complication. I don't like it. 
But maybe Carl tried to create push on programmers, pushing them 
to do sequency of read/write correctly?

seems like a lot of overhead too ...

i tested. Alternating read/write causes the buffer cleared each times

so the docs are correct

But the buffer is cleared only after a write action occured .

If you receive several read events the data are added to the buffer 
(buffer not cleared)

Yep, I think that's what I said above

ok, i just confirmed it with tests

i encountered the famous stack overflow bug.

Never never use a [wait] when you treat an event in the awake handler

I see in Gabriele's prot-http he has an http-awake handler that creates 
events which he passes on to another awake handler

yes but it"s fake events passed from tcp port thru the fake http 
port.

Actually, it's just calling the event handler function of the fake 
port

it's not asynchronous

it's a pity that we have to "fake" these events, currently

I'd love to be able to pass "real" events on, WAKE-UP would already 
be there, but other stuff seems to be missing

i tried sending with WAKE-UP from the tcp port to the scheme port, 
and the scheme port's AWAKE handler even got called

but a WAIT on the scheme port never returns, even though the scheme's 
AWAKE returns true

anyone can test this http://rebol.wik.is/Rebol3/Schemes/Ftp

the default timeout times out waiting for ftp.debian .. so I put 
a wait 10 seconds there!

I was trying to find a ftp site with a lot of data to read from ...

I may have some redundant waits there in the handler

try /debian/pool/main/x/ instead of /debian/dists/lenny/

that should give you a huge directory listing :)

ok

eeek... r3alpha crashed on me :(

heh :)

yeah ..doesn't get a complete directory listing ...

something must be wrong in my dataport event handler

missing a read port in the read event

only picks up 5355 bytes

I can pick up the rest doing a 
read cmd

sounds like it should be