World: r3wp

any refinement just makes call in encap go wild (on windows)  using 
dir as the command

my async-call function does polling every 0.5 seconds, there is no 
busy loop like in the original port scheme by Nenad (mine is an improvement 
over his code). note that it is GPL. (I would be ok with making it 
BSD, but the original code from Nenad is GPL). it uses timers.r though.

my version also supports linux, *bsd and mac osx. (osx we have troubles 
with though, still need to investigate it)

if only people would license librairies with LGPL ' :-/

of course i also have a kill-process function to kill the process. 
even on windows. :)

(i didn't believe it, but windows does not have any way to kill a 
process - you must create a new thread in that process with a call 
to ExitProcess... but this only on NT, older wins have no way to 
do this)

I know its one of the reasons render farm management apps on windows 
are sooooo hard to write

hehe, so where do I get your version of async-call  ;-)

you'll have to remove all the Detective dependent parts... then you 
should ask Nenad if it's ok to use it, unless your app is gpl :)

I might be able to coax him into releasing LGPL?

regarding your version...I don't mind the work...

No restriction using my version of async-call, I didn't remember 
it was GPL, it should be BSD. I'll change that .

http://www.colellachiara.com/soft/async-call-definition.r

ah, you're here. the file i had was gpl, let me check...

thanks guys  :-)

yep... my file is gpl. it's ok for me to change to bsd too. so you're 
fine maxim. :)

timers.r is on http://www.colellachiara.com/soft/libs/

together with other stuff you may need

you have some work to do... but it should be a good start.

Nenad is right, I looked in the release I got (v1.1) and its not 
gpl.  its basicelly BSD.

wrt stability have you guys encountered any limits or performance 
instability in some situations so far?

mmm, so probably the version i had - which was much before public 
release - had no license info, and i assumed gpl since the rest of 
the detective is gpl.

Nenad, would you like me to supply the improved ping-demo.r to you? 
 cpu useage is much more reasonable...

I heard once or twice that some exe won't run correctly under asyn-call 
(freezing or no output).

the detective does a lot of calls, and is fine. there are gc bugs 
in older rebols though. the latest sdk should be fine but i haven't 
tested it a lot yet.

If the solution is generic, you can send it here: [dockimbel-:-free-:-fr]

doc, iirc the cpu problem you had was with using async-modes: 'write, 
which is a busy loop. am i right?

yep :-)  just a plain drop in replacement to your app.  and can be 
applied to any other app.

i'm just doing a poll every 0.5 secs or so.

but Gabriele might have a better (real) solution

correction, 0.25

using my timers.r, real timers would be much better of course...

real timers - part of R3 Core? :-)

i really hope so :)

although with tasks they're much less needed, ie you can just use 
multiple tasks and wait.

Gab: it's not using 'async-modes at all, it's related to REBOL calling 
automatically 'get-sub-port when port/in/state/inbuffer points to 
a string! value.

will tasks be threads or processes?

threads

sorry (should be in R3 group)

doc, i see.

handlers really need a network subport, although you can do a lot 
of things without.

The busy loop is generated by REBOL itself, it's a side effect i 
was using in async-call to do busy looping on the pipe while allowing 
other port events to be processed.

yep... that's why i made it a function instead of a port.

i'm using a different trick to implement timers :)

then timers to do polling on the pipes. on linux instead, you just 
get a signal when the command finishes, and read from the pipe - 
no polling needed.

doc, did you have kill too? i think that's only on my code, but the 
distinction is so blurred :)

Nope, 'kill support was your code only ; )

well, here is another strange SDK issue.

after encapping, an application works well ONLY if I supply the full 
path to the binary !?!?!?

If I setup the path environment and use an encapped application using 
only the filename, windows resolves the path for me, but I get the 
following error: