Have been fiddling with the misc/procmessage example.
Sofar I haven't been abled to send/receive a signal/message from the child task to the main one.

O.k. this is what I need:
a) MUI-task running the user-interface
b) non MUI task getting "jobs" from the MUI task. This might run long on such a job so new jobs should queed till the task is ready again (I guess a MsgPort would be right here).
It should also be able to signal the MUI-task when a job is done
c) (later on) threads doing one big I/O operation and signaling the MUI-task when finished


From clancing over the MUI-doku (and exec/dos.doc) I can see 2 possibilities:

1) Process.mui
This is a bit underdocumented espcially how and when I can send info from and too that process

2)MUIM_Application_AddInputhandler
Again very little doku, and what can be found is all about the special case of creatin a timer.
This how I (don't) understand it:
-create a MsgPort and put it's mp_SigBit into ihn_Signals (or do I have to shift 1 << mp_SigBit ?)
-start the new task/thread and hand over that MsgPort
-do a PutMsg() in that new task (how do I init such a mesage ?)
-the method I set in ihn_Method should be called

-do it vice versa to send messages from main task to child

Just do make it clear, none of the child task will need to do anything MUI.

To communicate to main MUI task the best method is creating methodstack. Methodstack is based on MUIM_Application_PushMethod idea but is more versatile. Instead of pushmethod you would call methodstack_push() and methodstack_push_sync() functions.

I am too lazy to talk about it more right now but you find good example from Ambient source code.

Edit

You wrote:

Quote:

Even then it can be good idea to use custom MUI methods to notify main task when job is done.

[ Edited by itix 30.10.2011 - 17:17 ]

Completly missed Class4 example which seem to demostrate just what I needed

Had allready looked into that methodstack stuff, but failed to recognize how it connected to main task but I guess I'll get that covered too.

The methodstack allocates extra signal. When method is pushed to stack from subtask it uses this to signal GUI task. GUI task then just is triggered on this signal (it is manually checked in event loop) and pumps MUI methods from stack.

It is quite useful approach since it allows getting variables from UI (see how OM_GET is used with methodstack in Ambient).

In the end using methodstack and MUI methods works better than vanilla PutMsg(). Using PutMsg() requires you to define some structure and enum you wrap to some function call + parameters while you could do it directly with MUI methods.

For the moment I allocated a signal in the child process and can now trigger an event in it's loop (pretty much just like SIGBREAKF_CTRL_D is used in the example).

This will be expanded by some semaphored exec-list of "jobs" (which seems to be what Ambient is doing to just for the other way round).

The child will only need to send something along "your data is ready, update yourself" a simple PushMethod should be sufficient here.