@salass00 Thanks for the DOS packets reference, they are the communication layer, correct me if I am wrong. But before that I would need a bit of theory to understand what a handler is and how it really works. If I understand well a handler is basically a process which is possible to "call" through normal AmigaDOS file I/O functions such as Open(), Read() and Write(). Correct? Don' t we have a skeleton code or such?

@salass00 You are right, a semaphore or similar mechanism doesn' t make sense because multiple and concurrent calls to the handler don' t share any memory. Thus the handler manages a packet at a time with the work flow being like 1) get a packet GetMsg() 2) process packet 3) return packet PutMsg() and it doesn' t get a new packet 1) until the current one is returned 3). Please correct me if I have misunderstood something.

@salass00

That might be true come to think of it. ...

Well after our focus on topic, I see that not all handlers examined by me so far cover the mentioned aspects, thus there is a risk that they may not work as expected under the mentioned circumstances.

@salass00 Thanks for your interest. The handler concept I have in mind is a sort of "server" managing multiple requests from different "clients" (client-server model). I am now evaluating how to handle a flow of requests for each client: 1) by a new handler instance for each client 2) by a unique handler instance for all clients The handler needs to instantiate a timer for each client. The client work flow should be like this: - Open() - Send request 1, Write() - Send request 2, Write() - Send request N, Write() - Close() Surely 2) requires a bigger programming effort. I hope it is clear enough, what do you think about it?

@salass00 Thanks. I want to keep it as simple as possible, thus at the moment I am more oriented to create a new handler instance (automatically done by DOS) for each request / file handle. Now it is also more defined that in a normal case the handler itself should manage at most just a few requests.