Home   Archive   Permalink



confused by first http-port

The follow is source of webserver.r:
    
web-dir: %./www/ ; the path to rebol www subdirectory
    
listen-port: open/lines tcp://:80 ; port used for web connections
buffer: make string! 1024 ; will auto-expand if needed
    
forever [
     http-port: first wait listen-port
    
     while [not empty? client-request: first http-port][
         repend buffer [client-request newline]
     ]
     repend buffer ["Address: " http-port/host newline]
    
     parse buffer ["get" ["http" | "/ " | copy file to " "]]
    
     parse file [thru "." [
             "html" (mime: "text/html") |
             "txt" (mime: "text/plain")
         ]
     ]
    
     data: read/binary web-dir/:file
    
     insert data rejoin ["HTTP/1.0 200 OK^/Content-type: " mime "^/^/"]
     write-io http-port data length? data                
    
     close http-port
]
    
Here is some lines confused me:
while [not empty? client-request: first http-port][
         repend buffer [client-request newline]
     ]
Why and how "first http-port" will return each line of http-port?
Very thanks for some's help about Port!.

posted by:   limux       15-Dec-2010/10:38:41-8:00



Reading the data of a direct access port with copy function will move port's head forward. So the port will always be at it's head position.
The http-port in above codes is a port with direct refinement, isn't it?

posted by:   limux       16-Dec-2010/6:51:20-8:00



Ping-demo: I can reproduce your issue. I've increased the sleep delay in async-call.r (OS/Sleep line) to 10ms and it's now stable here. I've uploaded the patched version at: http://sidl.fr/async-call.r
    
    
Notepad: I'm not sure what you're trying to achieve in your console example...call:// is an asynchronous scheme, so it requires proper initialization and an event loop in order to run, like this:
    
     p: open call://
     p/locals: make p/locals [                     ;-- install at least one callback
         show-window: yes
         on-completed: func [port][probe "closed!"] ;-- see ping-demo.r for other callbacks
     ]
     append system/ports/wait-list p                 ;-- add the port to system's wait list
    
     insert p "notepad.exe"                         ;-- init a new job
     do-events                                     ;-- starts an event loop
    
     ...
     "closed!"                                     ;-- printed when notepad.exe is closed
    
If you just want to run a command without blocking, the native CALL does the job well. Call:// was designed to address the specific case where you need both non-blocking call and getting stdout data from the called process while it's running.
    
Remember that this is a hack in REBOL event/port system (because real custom events cannot be generated in R2, not sure for R3), so events are faked by forcing REBOL to call the scheme's event handler code by using a polling method (with now a 10ms delay between each poll). I can't guarantee that this will work reliably in all contexts.


posted by:   DocKimbel       16-Dec-2010/7:04:03-8:00



This forum is messing up posts in different threads. My post above was supposed to appear in "Process execution?" thread, not here...

posted by:   DocKimbel       16-Dec-2010/7:06:42-8:00



Doc,
    
That was a known bug that I never had a chance to look at. It should be fixed now :)

posted by:   Nick       17-Dec-2010/2:18:44-8:00