passing arguments to a CreateNewProc process....etc.

[Piru]

@Noster

you could send a kind of startup-message to the messageport you get as result of the successfull CreateNewProc(). This message will be send to the new process's pr_MsgPort.

Small clarification:

CreateProc (ks 1.x+) returns struct MsgPort *
CreateNewProc (ks 2.x+) returns struct Process *

So with CreateNewProc you must send the message to newproc->pr_MsgPort

@Jose

2/3: It sure is possible to pass arguments, and even have the function report back "results". It's rather trivial really, you just need some messageport to send msgs and then wait for replies. If you need timeout, you can build it into the subproc: just abort the operation when timeout occurs, and return "timeout" error.

Here's a small framework of a subproc IPC: http://www.iki.fi/sintonen/src/ipc/

Note that the code uses seglists, but it could easily use NP_Entry instead.

[Piru]

@Dietmar

It's easier to pass AllocVec()'ed data in task->tc_UserData. NP_UserData should do the trick but I install it manually, with handshaking via signals. Tasks FreeVec()s the data when done with it.

This works, but you must be careful to Forbid() before CreateNewProc() and only Permit() after you've poked the tc_UserData, or you will get rather hard to track race condition.

[Piru]

@Georg
CreateNewProc doesn't break forbid when both input and output handles are "NIL:", (and NULL path, currentdir, cli etc are requested). This is semi-documented, as the system must somehow launch the initial process before filesystems and disk I/O is available. The first process is launched from within a task. Obviously this only can happen if CreateNewProc works without any dos I/O calls. However, depending on this indeed is a bit hacky. The signal method is nicer, agreed.

@Dietmar

SIGF_SINGLE

SIGF_SINGLE might be dangerous to use, at least if there are any semaphores involved. IMO SIGBREAKF_CTRL_x is better.

If the subproc is supposed to return success/failure indicator, or if the subproc should handle possible multiple events, it might pay off to use full message based system. It can be done with pure signals and poking some variables, but IMO it's not as clean as messaging.

[Piru]

@Noster

This is hacking and might not work in future releases of the AmigaOS (or if you wish to release a MorphOS or AROS version of your program)..

It might be hacky, but we've been careful not to break it in MorphOS. Poking tc_UserData, using manual signal sync etc works just fine. It might not be pretty though...

@Dietmar

SIGF_SINGLE signaling was apparently documented on a developer CD. I suppose I picked up its use for task handshaking via Olaf Barthel's Term source code. It had a funny comment: "Task termination and handshake signal. Note: don't try this at home kids, we are all trained professionals here!".

Yeah SIGF_SINGLE is fine most of the time, but it can bite back. There are numerous cases where usage of SIGF_SINGLE has caused lots of grief (for example ramlib semaphore vs. library/device initcode). SIGF_SINGLE is used by the system itself, at least for semaphores.

It's much better idea to use the "user signals", SIGBREAKF_CTRL_F for example.

[Piru]

can't find NP_UserData tag Dietmar mentioned anywhere. I was supposing it's a tag for CreateNewProc() ? Is it an AOS3.9 only thing?

It's AROS/MorphOS thing. AmigaOS 3.x doesn't have it. No clue if AmigaOS 4 copied it.

I was also about to use the process own port but the RKM's advise against using it, saying it's for exclusively use by DOS. I guess if I use it only in the beginning before using any dos function I'll be alright?

Exactly.

Anyway, I'd prefer that NP_UserData tag, it's more practical

Too bad it's AROS/MorphOS thing.

-EDIT- MorphOS actually interherited the tag from AROS :-)

[Piru]

@falemagn

Oh, hehe. Right :-)

Anyway, the tag rules indeed. You get rid of that nasty sync/poking crap. Nice idea.