English Amiga Board


Go Back   English Amiga Board > Coders > Coders. System

 
 
Thread Tools
Old 30 November 2020, 16:50   #21
bloodline
Registered User

bloodline's Avatar
 
Join Date: Jan 2017
Location: London, UK
Posts: 358
Ok, some more, perhaps stupid questions.

When you open a device, you establish a “communication channel” with that device via a single IORequest messsage. So you can use this to submit commands to the device and receive responses (if required), via this IORequest.

What formal process is there for streaming commands to a device? Say that I don’t care about any response, I just want to send an arbitrary number of command messages to the device, and it is up to the device to handle them (or not), my task doesn’t care, it just wants to send several command messages and then move on (maybe terminate, or whatever), relying on the device’s message port queue to ensure the device received them.
bloodline is offline  
Old 30 November 2020, 18:37   #22
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 857
Quote:
Originally Posted by bloodline View Post
When you open a device, you establish a “communication channel” with that device via a single IORequest messsage. So you can use this to submit commands to the device and receive responses (if required), via this IORequest.

What formal process is there for streaming commands to a device?
You allocate as many IORequests as you need, open the device with one of them, and then memcpy the IORequest to all other allocated requests. Then, you SendIO() the requests in any order you seem fit, and the device handles them "first come, first served".


Typically, you would allocate a limited number of requests and SendIO() them, when you run out of them, you wait for the signal of the reply port, and then CheckIO() which of the requests became ready. On such a request, you WaitIO() to dequeue it from the port - it is then ready for recycling, and can be SendIO()'d again.


The FFS (and many other file systems) create IORequests whose io_Node.ln_Name points to a struct DosPacket of type ACTION_READ_RETURN or ACTION_WRITE_RETURN. This way, when the packet is replied by the device, the FFS (or other handler) receive a "pseudo packet" of the particular type (ACTION_READ_RETURN) and then continue with the activity.


Actually, what FFS does is that it creates a co-routine for every file handle, and on ACTION_READ_RETURN this co-routine continues to operate. As of 3.1.4, CrossDos and the CDFileSystem work the same - this way, FFS can continue to serve requests while the device (e.g. the trackdisk.device) is busy.
Thomas Richter is offline  
Old 30 November 2020, 21:00   #23
bloodline
Registered User

bloodline's Avatar
 
Join Date: Jan 2017
Location: London, UK
Posts: 358
Quote:
Originally Posted by Thomas Richter View Post
You allocate as many IORequests as you need, open the device with one of them, and then memcpy the IORequest to all other allocated requests. Then, you SendIO() the requests in any order you seem fit, and the device handles them "first come, first served".
Excellent that’s exactly the behaviour I was expecting. I did wonder if I could just make copies of the initial IORequest and send them as needed, but that felt a little “clumsy”/kludgy?


Quote:
Typically, you would allocate a limited number of requests and SendIO() them, when you run out of them, you wait for the signal of the reply port, and then CheckIO() which of the requests became ready. On such a request, you WaitIO() to dequeue it from the port - it is then ready for recycling, and can be SendIO()'d again.
This feels like a very efficient way to do the IO!
As you are essentially batching all your requests.

Quote:
The FFS (and many other file systems) create IORequests whose io_Node.ln_Name points to a struct DosPacket of type ACTION_READ_RETURN or ACTION_WRITE_RETURN. This way, when the packet is replied by the device, the FFS (or other handler) receive a "pseudo packet" of the particular type (ACTION_READ_RETURN) and then continue with the activity.
That’s a rather clever little hack! Though it’s a shame it couldn’t be implemented in a cleaner way.
Quote:
Actually, what FFS does is that it creates a co-routine for every file handle, and on ACTION_READ_RETURN this co-routine continues to operate. As of 3.1.4, CrossDos and the CDFileSystem work the same - this way, FFS can continue to serve requests while the device (e.g. the trackdisk.device) is busy.
This was actually what started me wondering about queuing device IORequeats, there is often no need to block, just let the device handle the messages when it gets to them!

Many thanks for your insight again!
bloodline is offline  
Old 30 November 2020, 21:17   #24
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 857
Quote:
Originally Posted by bloodline View Post
Excellent that’s exactly the behaviour I was expecting. I did wonder if I could just make copies of the initial IORequest and send them as needed, but that felt a little “clumsy”/kludgy?
You can, but you need to do after opening the device, so the order is important. Actually, what is really needed is to initiialize io->io_Device and io->io_Unit, so copying that over is also sufficient. A memcpy() is just simpler and also does the job.

Quote:
Originally Posted by bloodline View Post
That’s a rather clever little hack! Though it’s a shame it couldn’t be implemented in a cleaner way.
A cleaner way would be to use two separate ports, one for the incoming packets the handler is supposed to answer, and another port for the IORequests coming back from the device. So it is possible, it is just not necessary.


Quote:
Originally Posted by bloodline View Post
This was actually what started me wondering about queuing device IORequeats, there is often no need to block, just let the device handle the messages when it gets to them!
Typically not, but there is a catch if two incoming requests attempt to alter the same block or the same state of the file system. The FFS has a very complex co-routine system plus "wait queues" for the co-routines to avoid the trouble. The CDFileSystem and CrossDos is multithreaded as far as data transfer is concerned, but the administration logic is single-threaded - unlike the FFS.


The FFS is actually smarter than one thinks - at least as far as the asynchronous I/O handling is the case. The adminsitration disk structure is from days in the past.
Thomas Richter is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Exec library codes millis support.Other 2 21 July 2017 20:22
LVO tables in exec libraries bloodline Coders. System 2 25 February 2017 16:35
CDTV exec.library Arnie support.WinUAE 19 18 February 2016 14:11
debugging session with exec lib pixel Coders. Asm / Hardware 4 21 May 2014 00:49
exec.library problem with VisualPrefs oldpx support.Apps 4 29 August 2002 01:18

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 06:50.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.08830 seconds with 15 queries