World: r3wp

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.

Can you point me to that docs?

That was maybe with the experimental 2.5.5x async Core. It was released 
as alpha only IIRC, but never made its way in the official branch.

looks like it.

It was very close (same API) to what Carl did for R3 (I think he 
just cleanup the code from that old alpha version).

I am porting an app to the latest cheyenne, I tried -vv and -vvv 
and uncommented the debug option in cfg file but I can't make output 
+ error  -- in case of error - show up in the browser. I saw trace.log 
and chey-pid*.log but that doesn't help me debug current case. Is 
there a way to show in browser while developing?

the current problem is that something is undefined which suggests 
that it doesn't load some of my library files. I did this in   on-page-start 
before (during development - I intended to move it to on-application-start 
when it's in full production mode). First thought is that that function 
doesn't execute so I put print "zzzzzz" into it and look the output, 
but I am unable to see the output before error hapened with my current 
knowledge now as browser always shows the "Sorry this page cannot 
be displayed" page and the log files don't hold that string either. 
(I tried adding print "xxxxx" above function that causes error too 
so I know it get's executed and I couldn't  find the string in any 
output or log file

( Is there a way to show in browser while developing <== Is there 
a way to show whole output + error output in browser while developing, 
like it worked before )

cool.

I don't know what I did but now I see output in browser..

now that I can see output this is what's going on... I see that on-page-start 
is called, I do " do %bin/somelib.r   do %bin/somelib2.r ..." there 
, but libs don't seem to get included

What Cheyenne version are you using?

For showing errors in the browser, just put the DEBUG keyword in 
the webapp config block.

I guess you're using 0.9.19. DO has been redefined in the RSP engine 
to bind, by default, loaded code to webapp context. If you want to 
load libs that have to be visible in the global context, you have 
to use DO/GLOBAL.