Actually we have at least 2 of them. However, my "top" can't be used in DOS or ARexx scripts since it running infinitely until you stop it with Ctrl-C, but maybe Capehill's "Tequila" can be used that way.
That thread was mostly discussion then I found some links on the end.
But what I meant was a command or tool built in. It's becoming common that I find or rather don't find what I thought would be an obvious tool built into the OS. It's likely using what other OS has and then I realise something so obvious like even a basic process monitor doesn't come with OS4.
But what I meant was a command or tool built in. It's becoming common that I find or rather don't find what I thought would be an obvious tool built into the OS. It's likely using what other OS has and then I realise something so obvious like even a basic process monitor doesn't come with OS4.
Most of what an Unix top does is impossible on AmigaOS: - Each Unix task has it's own virtual address space and it's always know which, and how much, memory is allocated/used by it. On AmigaOS 99% of the memory is shared between all tasks instead and even the OS doesn't know which task owns/uses how much and which parts of the memory. (There are some exceptions in AmigaOS 4.x like MEMF_PRIVATE and the extended memory system, but such new parts of the OS are rarely used.) - Unlike the old AmigaOS 1.x-3.x/m68k Exec task scheduler the AmigaOS 4.1 ExecNG/PPC one does track the CPU usage of each task, but only on CPUs with the required hardware support, which is used for example by performancemonitor.resurce as well. A system legal way, if you have access to the internal ExecNG includes, is possible - but it can't work on all systems/CPUs supported by AmigaOS 4.x, only the ones with CPU support for performancemonitor.resource.
As a result all what's possible for tools which can be used on all systems running AmigaOS 4.x are hacks, like my top and Capehill's tequila.
On AmigaOS 3.x similar tools like Scout, SysMon, etc., which could display some system internals, incl. CPU usage per task, did exist as well, and even extreme hacks like Executive which reimplemented and (nearly) completely replaced the m68k exec task scheduler where available. But they had a lot of problems, more than tools like top and tequilla on AmigaOS 4.x, especially Executive broke much more software than it could improve.
AROS on Linux seems to come with a task monitor. Not sure how portable it is (didn't check yet).
The main development goal of AROS seems to be being intentionally as incompatible as possible to anything, and that's not just limited to AmigaOS 3.x/m68k and AmigaOS 4.x/PPC, but even to other AROS versions. Not only incompatible to big-endian native AROS versions like m68k, PPC or efika in the little-endian versions, but AFAIK even native AROS x64 versions can't use any code nor data from native AROS x86 versions. Hosted versions like the Linux one even more so, AFAIK the AROS tasks are simply host tasks in such hosted versions (for example Linux tasks), i.e. there is 0% compatibility to any AmigaOS exec task scheduler and a Linux hosted AROS task monitor is probably just a Linux task monitor (maybe filtering out non-AROS tasks) and there is nothing at all which could be ported to neither AmigaOS nor native AROS versions. The big advantage of hosted AROS versions is that they don't have to implement any hardware drivers, they can simply use the ones of the host OS instead.
joerg wrote:@Capehill Hosted versions like the Linux one even more so, AFAIK the AROS tasks are simply host tasks in such hosted versions (for example Linux tasks), i.e. there is 0% compatibility to any AmigaOS exec task scheduler.
No, that's wrong. Linux does not see or know about Exec tasks inside AROS hosted. Everything is still basically the same as AROS native. What AROS hosted does is to basically emulate/implement interrupts using Unix signal handlers. And for task switches in the Unix signal handler it simply pokes the sigcontext (containsing cpu/fpu context state) structure, so that after the return from the signal handler, the Linux process "AROS" continues executing code from a different AROS Exec task.
A bit like early Linux user lever threading libraries.
Disable()/Enable() for example then works by simply blocking/unblocking Unix signals.
Quote:
The big advantage of hosted AROS versions is that they don't have to implement any hardware drivers, they can simply use the ones of the host OS instead.
Btw, it's really "can use", but does not mean "has to use" at the same time. Some native gfx drivers were developed under hosted version.
Btw2: there are several other big advantages.
It "boots" extremely fast, takes up almost no host cpu time/resources. You could run big number of instances at the same time (https://vimeo.com/191163338 - each blue amiga-style window appearing is a newly booted/running AROS instance, running intermixed with Linux windows). Then if you run one (big) program in once instance, and other (big) programs in other instance, you basically get some kind of memory protection/resource tracking/etc. for free.
You can do symbolic debug of the whole OS including all system libs/tasks and app tasks/libs with gdb, as if it was one single application.
Yes, reading AROS sources is always good for having a lought, and a great inspiration for how things should not be implemented, for example the funny AROS file system API 🤣 Of course the ancient TRIPOS/AmigaOS 1.x-3.x BCPL packet file system API is crap and should be replaced, the AmigaOS 4.x dos.library did that as well - but using a better solution. The AROS developers somehow managed to make it even worse, by using the exec device API instead 😮
Was removed and replaced with std. AOS classic packet filesystem API long ago.
Quote:
the AmigaOS 4.x dos.library did that as well - but using a better solution.
It's easy to get into trouble when trying to replace something old/bad even if intentions are good. For example are there rules in the "better solution", when filesystems now run stuff in app task which used to run in filesystem task, for things like signal/msgport alloction (app is allowed to theoretically use up all the dynamically allocatable ones). Or stack usage? Are filesystems now supposed to check for potential low free stack and then stackswap?).
@Georg I don't use the new FileSystem API in my AmigaOS 4.x file systems (SFS, JXFS, CDFS, etc.), the new FS API was only implemented several years after I implemented my own FS API for SFS, etc. (it's similar, but not compatible), therefore I can't comment on the official OS4 FS API but only my own one. - Allocating signals for device I/O used by the FS code running in an application tasks isn't required, and may fail if all signals are used already, but you can use SIGF_SINGLE or SIGF_DOS instead. - My file systems just check the available stack size. If it's too small for executing the FS code inside the application task it's simply forwarding the commands to the still existing priority 10 FileSystem task, i.e. it's slowed down to the old TRIPOS/AmigaOS 1.x-3.x method, but using StackSwap() instead should usually be the better solution.
Working on a small project that monitors a file download and performs an action when completed. Currently looking for the file comment to be entered but would prefer a more robust solution.
Well, I got my Arexx script working, but thanks to Tequila, I can see it is grabbing all the CPU bandwidth and killing performance.
How can I change the task priroity of a arexx script?
I'm going to look into WaitNotify, it might be more helpful.
Otherwise, I will finally have to learn a proper programming language... have been eyeing PortablE for a while.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
