World: r3wp

Graham: no problem here, testing with 0.9.18 binaries and 0.9.19 
source version, can't reproduce that crash (all tests done on port 
80). WinXP-Pro-SP3 here.

I'm on vista and using port 8002

Do the Cheyenne processes disappear when your test fails? If not, 
did you try to access a web page to see if it's still responding?

try => tried

I'm watching the task manager ... all 3 cheynne processes quit

I think timing is critical for this bug to appear

ie. if I add a print between the open and close, the bug does not 
appear

I'm trying here with the code you've posted (without the print), 
but can't reproduce.

Hang on ...

http://screencast.com/t/cPpSejdtYZ

watch the task manager

Could you please try with the source version (v0.9.18) from here 
: http://cheyenne-server.org/dl/cheyenne-r0918.zip?

Btw, did you checked for a %crash.log file near cheyenne.exe?

ok. dl now

1-Jan-2009/9:16:46+13:00 : make object! [
    code: 305
    type: 'script
    id: 'invalid-arg
    arg1: true
    arg2: none
    arg3: none
    near: [set-modes new [no-delay: on]]
    where: 'init-connection
]

does that help?

forgot about crash.log

Ah, interesting.

still want me to test with source?

Yes, can you just comment the following line in %UniServe/uni-engine.r 
file :

	if new/scheme = 'tcp [set-modes new [no-delay: on]]

then try again your test.

Seems that Vista is more picky than XP about the usage of Nagle algorithm.

oops ...

>> do %cheyenne.r
Script: "Cheyenne Web Server" (19-Feb-2008)
** Script Error: NT-service? has no value
** Where: boot

** Near: if all [NT-service? not flag? 'service] [set-flag 'tray-only]
>>

Did you applied some TCP networking tweaks on your Vista box to improve 
network latency?

nope

REBOL/View 2.7.6.3.1 14-Mar-2008
Copyright 2000-2008 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM
>> do %cheyenne.r
make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'context
    arg2: 'blk
    arg3: [block!]
    near: [extension-class: context list]
    where: func [/local list][
        list: extract phases 2
        forall list [change list to-set-word list/1]
        repend list [to-set-word 'service none]
        extension-class: context list
    ]
]
>>

Yes, old bug of 0.9.18 with REBOL 2.7.6.

Doc, do you have a time planned for the public release of 0.9.19?

Either use an older REBOL core or apply the following patch to Cheyenne 
: http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=<9May2008113928682359200>

BrianH: I should have released it a month ago, but some issues with 
RSP showed up and I like to fix them before releasing officially 
the new version.

I ['d] like...

Basically, some errors are not reported or (not catched?) during 
RSP execution. I want to clean up the RSP logging code to output 
all errors to a log file.

with no changes, Cheyenne no longer shuts down using the source version

using 2.6.2

Does that help?

Well, it seems to show that something changed between 2.6.2 and 2.7.6. 
I'm writing a short test server to see if it can be reproduced with 
a short block of code.

what is the current version of cheyenne encapped with?

2.7.6 ?

2.7.5

Ok, try this : paste the following code in a fresh console (2.7.6) 
and try to reproduce the error :

s: open/binary/direct/no-wait tcp://:8003
append system/ports/wait-list s
s/async-modes: 'accept
s/awake: func [server-port /local err new][
	either error? err: try [
		new: first server-port 
	][
		err: disarm err
		if err/code <> 517 [?? err]
		false
	][
		insert tail system/ports/wait-list new
		new/async-modes: [read]
		new/awake: func [port][
			print "event received"
			probe copy port
			false
		]
		set-modes new [no-delay: on]
		false
	]
]
set-modes s [no-delay: on]
wait [ ]

Test with : p: open/direct tcp://127.0.0.1:8003 close p

goes into an endless loop

Does Cheyenne use the EXTRACT function? A bug with EXTRACT with binaries 
slipped into 2.7.6. DevBase has a fix.

event received
none
event received
none
event received
none
event received
none
event received
none
event received
none
event received
none
event received
none
event received
none
event received

BrianH: yes, that's related to EXTRACT but not with binaries, it's 
a side effect of EXTRACT with hash! values.

Graham: does the test line output an error?

no

mmm...if it's really related to some precise timing, it will be hard 
to track.

>> wait [ ]
** Script Error: Invalid argument: true
** Near: set-modes new [no-delay: on]
false

just tried it again

Ok, so we can now fill a nice RAMBO ticket, with an example code 
:-)