World: r3wp

Janko, is your testing engine async ?

I'm not sure why you would want to use SSI from RSP .. but feel free 
to document it.

Will, no. It is not like load testing app or something like that 
, it is meant to test functionality of webapp backends -- if they 
do as they are supposed to

I never saw anyone using SSI. This is so oldschool :-)

Graham, read above. And Petr, it ight be old school but this doesn't 
imply it's not useful.

I haven't used SSI for over a decade ... and my recollection is that 
you can do all of that stuff in RSP.

doc, I really need your help.  I've tried quite a few things, and 
cheyenne is starting to behave more like a "chienne" than I would 
like.  ;-)


its funny cause I am trying to prevent cheyenne from doing its magic, 
and in effect, it feels like I'm trying to tell a shaman to stop 
having visions.

I'm almost there, but right now, when I close a connection, it effectively 
terminates cheyenne and all the task handlers    ' 8-o

Une chienne ! ça veut dire quelque chose de particulier en Québécois 
? Parce que pour un français ça fait assez vulgaire ;-)

ca veux dire la meme chose   ;-)

mais ca sonne assez similaire heheheh

Ah ok, j'avais pas saisi la blague :-)

it seems I cornered why cheyenne was dying on port close... yippe... 
but I still have a question.

I'm listening.

hehehe  I hope you didn't my above comment to harshly... its not 
a critique of the tool...  

let me make it clear... cheyenne is GREAT.


its what *I* am trying that is making it react strangely... but I'm 
understanding more and more as I beat it up.

Btw, you can run Cheyenne in verbose mode (-vvv or even -vvvvv), 
it's easier to debug this way. During the boot process, Cheyenne 
will list mods callback matrix allowing you to see/debug the execution 
order for your mod's callbacks.

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