Performing IO from (or rather, on behalf of) exec Tasks

[Karlos]

Hi,

I was thinking about this problem recently. One of the main drawbacks of using exec.library Tasks for me is the restriction that they can't use dos.library IO, or anything which would in turn cause a dos.library IO call. This would seem to rule out any iostream / cstdio as a consequence.

As a result of this, I used dos.library Process as the basis for a Thread class. It might be a bit churlish, but I always felt it was overkill, especially when a particular Thread might never actually do any IO (but you aren't in a position to guarentee it).

I was wondering, is it feasable to use a Message/MsgPort mechanism where a single Process would listen for incoming 'IO service request' messages from Tasks, then perform the IO on their behalf?

Such a mechanism would be wrapped behind a simple class interface so that you don't have to be aware of how it works (naturally). The main provisio would be that you have to use this provided IO class over anything in the standard library when writing code that uses the Thread classes.

Does this seem a feasable idea?

-edit-

Yay, finally thinking about coding *outside* of work!

[itix]

It might be a bit churlish, but I always felt it was overkill, especially when a particular Thread might never actually do any IO (but you aren't in a position to guarentee it).

It is not overkill. Processes are not slower and they dont use more memory than tasks (except for pr_Process structure).

I was wondering, is it feasable to use a Message/MsgPort mechanism where a single Process would listen for incoming 'IO service request' messages from Tasks, then perform the IO on their behalf?

It would just make coding more difficult.

[Karlos]

itix wrote:

It would just make coding more difficult.

As I said, it would be hidden from the developer behind a class anyway.

[Piru]

...and as itix said it have absolutely NO benefit at all. Just use process. You can use PR_ tags to turn off all cloning of the parent process structures, that way process will only use sizeof(struct Process) - sizeof(stuct Task) more memory.

However, if you want to get hacky... dos.library has some provision for tasks calling dos functions since OS V36. Basically it means that DoPkt() - which is used internally by dos - does create temporary msgport when needed.

Also, there are more problems with this: It seems the task-calling-dos support is incomplete. DOS pokes pr_Result2 directly, trashing innocent memory after struct Task. Also dos.library will happily put up a requester, which in turn will use pr_WindowPtr to determine where to put up the requester. This particular problem can be worked around by allocating sizeof(struct Process) for the task, and setting up the fields to some sane values (say: -1 for pr_WindowPtr).

In all, while it's possible to do this hack, or to offload the dos.library calling to some subprocess, in short: It is really not worth the trouble.

[Karlos]

...and as itix said it have absolutely NO benefit at all. Just use process. You can use PR_ tags to turn off all cloning of the parent process structures, that way process will only use sizeof(struct Process) - sizeof(stuct Task) more memory.

My existing code does this already, to be honest; I was just looking at the problem from a different perspective to see if I could get away with using just Task as the basis for the Thread class.

It was a fun thought experiment, if nothing else :-)

[Karlos]

Well, regardless of the advice I tried it anyway, just to see.

I set up a Process that was a static member of a quick and dirty IO class (featuring output only at the moment).

Other members of the class include a MsgPort and FILE*. On instansiation, the MsgPort is created. Once you run out of free Signals for the port, instansiating the class throws an exception, but you'd not never really need to creare more than one instance per Task.

The test output method was simply print(const char*). The method creates a message, sends it to the internal static process and waits for the reply before returning. The message simply carries the two pointers and has a return value field.

The open() and close() methods also called the internal Process.

The internal process sits waiting for messages and then processes them as they arrive.

In all it worked just fine as a proof of concept. There seemed to be no side effect issues arising from the usage.