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!

[Karlos]

itix wrote:

It would just make coding more difficult.

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

[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.