World: r3wp

Max, come one, I didn't yet lost my sense of humour :-)

one = on

first I want to confirm that     flag-stop, returned in most low-level 
funcs    is used to stop cheyenne itself.

yess I have used the verbose, and it has helped me a lot  ;-)

:-) 'flag-stop is a very low-level flag for UniServe allowing to 
quit the 'wait loop. You shouldn't mess with that when working at 
Cheyenne mod level (even at Uniserve's service/protocol level).

ok, that is what was killing uniserve earlier... now I can rest in 
peace with that issue.

second question: maybe not specific to uniserve, but you are probably 
the best suited to answer it, since you've most probably played the 
most with async ports.

IIRC, there's the built-in 'stop-events function available for UniServe's 
services/protocols to allow clean exiting from wait loop.

how can I make sure that I/O writing to an async port is finished, 
before I close it.

my current fix is less than elegant, and most definitely will trip 
a server under load... (wait 1  ;-)

IIRC, when writing on an async port in R2, you're supposed to set 
the 'write mode in port/async-modes. That will make REBOL keep calling 
port/awake function until all the data has been sent.

Not sure what you're trying to do, but, you shouldn't need to lost 
time of low level async stuff. UniServe is meant to offer a complete 
client and server API that should save you from working on low level 
stuff (unless what you're trying to do is not supported by UniServe's 
API).

of low = on low

no, what is happening is that task-handlers hang (for known and uniserve-independent 
reasons) so I can't rely on the normal uniserve system.


I must catch further connections as soon as possible, since they 
have to report errors without triggering the installed mods.  going 
through the different levels of apis, really complicates this handling, 
which now, basically is all done within the on-accept awake func 
of uniserve.


based on your note about the async I/O above, I think I'll add an 
extension to on-data to handle the specific case where that specific 
connection was refused, waiting for the error report to finish and 
I'm all set.

To make a more complete answer to your data sending question : I'm 
don't remember precisely, but I think that  REBOL signals that all 
the outgoing data has been processed by calling again port/awake. 
It's then, up to the programmer, to decide if :
    - there's more data to send

    - no more data to send, so get back to a read-only state (this implies 
    unsetting the 'write mode in port/async-modes)
    - the port needs to be closed.

in this system, I'm not even reading the request, just knowing that 
its httpd is enough for me to react appropriately.

Are you opening/closing the httpd service dynamically when some new 
connection is opened?

nope, just handling the connection itself.

when task handlers come back to life, the connections start being 
accepted again.

there are also alerts being sent for people to know that something 
is going on.

you see right now, I'm not even calling  init-connection  !

Why do you need to intercept it so early?

I've just re-read what you've explained yesterday. So you're doing 
some sort of soft firewalling inside "chienne"?

I guess you could say that!

hehehe

funny cause you know how in french it sounds so similar... hahahaha

;-)

ok reading a bit more of the read/write low-level... I am sort of 
assuming by what I see that write-io is blocking? mode transfer

so for each part of data that write-io dumps, that function will 
wait for the actual tcp xfer to finish... Am I dreaming?

No, write-io is not supposed to block in async mode. The comment 
at line 433, is not accurate enough.

It should be "potentially blocking operation".

That means that the outgoing buffer is not yet empty and that the 
write-io would block in that case (but that case is not allowed in 
async mode, so an error (code 517) is raised, allowing you to escaped 
and wait the next call to awake to retry a new write operation.

R2 async mode was never really finished. The way it works looks really 
like a ugly hack on sync mode. But anyway, it works.

escaped = escape

ok so basically you can be awaken while writing is still going on 
within the previous awake call... but the first one is still blocked, 
until that first write-io is done.

have I got it right?

(the first awake call, that is)

nope, you're not blocked by write-io. It returns at once (raising 
a 517 error if a writing operation is still going on).

ok, I see.

When you issue a successful write-io, the data is placed in a outgoing 
buffer processed asynchronously the TCP/IP stack while your REBOL 
code continue execution.

and what If I don't add 'write to the port/async-modes.  will write-io 
then be blocking?

Not sure, maybe.

ok, I'll do an out of uniserve test to see.

There's maybe some info about that flying around in the mailing list 
archives from RT staff (Holger or Jeff probably).

so there really is no sure fire way to know if the write really is 
done, when in async.

does the tcp stack awake us when it has finished?

unless I do a write-io and catch the 517 error... that would be an 
ugly way to poll the system, until it stops raising an error... hehehe

basically putting the write-io in a loop with a try within... waiting 
a small amount between tries... ugly but probably functional.

Yes, ugly, but that's AFAIK the only way to know when the data has 
been really sent. Btw, IIRC, REBOL is already doing busy looping 
in async mode to fire the awake event for 'write async mode.

in the async port specs, there is question of 3 args for the callbacks... 
how is that uniserve only uses the port parameter... is this because 
the port enters async mode after its been opened normally?


cause I remember building an async-port enabled application and it 
does have a write-done action.

callbacks being called "handler" in the docs.