Comments on: Smoother LAUNCH function?

There have been a few discussions here and there about making the launch function a bit "smoother" in operation.

I'm in favor of making such changes, but there are always some issues when you're passing source out through the shell and back into another instance of REBOL via the command line. There's probably some kind of decent balancing point that's not perfect but gets us most of what we need.

Henrik has suggested:

if arg [append args mold/all arg]

but, that he notes a quoting problem with that (a bug?)... so another method would be:

if arg [append args to-binary mold/all arg]

But, of course, that is hex encoded.

Let's figure this out. If you have some ideas, please post them, the sooner the better.

4 Comments

Comments:

-pekr- 28-Sep-2010 15:32:23	While 'launch is fine for the simplicity cases, I just hope this is not a replacement for proper tasking/IPC :-)
Henrik 28-Sep-2010 15:37:06	It should not be used for tasking/IPC (way too slow), but it came up as it's required by the build system and there are some problems with transferring arguments cleanly from a LAUNCH to the launched process. With my few tests, a binary! seems to be the only way to make sure every molded part gets through.
Gregg Irwin 29-Sep-2010 17:34:15	A long time ago I requested a breakdown and examples for how CALL, RUN, LAUNCH, and DO/ARGS are intended to be used, and clarify what is different, and what is the same for each. What does the launched app receive, and what do you get back? CALL is the most general, and the others are all built on top of it, correct, even do/args? And please don't rule out using this for many IPC scenarios. I do this a *lot* in R2. Coarse, heavy processes are still useful. I actually think it's one of our most important IPC mechanisms. *nix's many small tools model and all that.
shadwolf 5-Oct-2010 22:21:28	once again the question is aiming the side of the target not the bull eye at the center of it ... ok here is the freaking main problem with this launch /run/call/do thing once you started any of them sub process your main program completly loose control upon those sub /side processing that's ok to call a closed process something with a determined begining and end but this doesn't fit a loop based sub process. in this case the sub process is completly undependant of the main one who created it. thread system have this good all along the life time span of the thread your main sofware keep a close control upon the threads he created and if for some reason the ideal condition are not existing anymore then the threads are stopped and dealocated until the right conditions return... without this kind of management you lack alot of what means modern computing in my opinion.

Post a Comment:

You can post a comment here. Keep it on-topic.