@Capehill I don't remember how I did it, but it's probably simply using IExec->SetMethod() to functions increasing a counter and calling the original functions.
I don't know why you are using own StringLen() and CopyString() functions instead of C library strlen() and str[nc]cpy() functions, but if you want to use own implementations don't use such extremely slow versions. For example check the newlib sources for an unoptimised and very slow (no CPU specific code like AltiVec used), but still much better than what you are doing, version of strlen(): https://github.com/eblot/newlib/blob/m ... wlib/libc/string/strlen.c A little bit better PPC assembler version (no AltiVec, data cache touch, streaming, etc., support code either): http://cvsweb.netbsd.org/bsdweb.cgi/s ... type=text/x-cvsweb-markup
Probably because I needed to call these between Disable/Enable and I wasn't sure if the C lib versions were safe to call. I can just replace those with strlen and strncpy.
@Capehill There is too much Disable()/Enable() usage in your code anyway, most of it can be removed or replaced by atomic accesses. But simple Newlib C library functions like strlen() and strlcpy() (the usually better replacement for strncpy()), which don't do any I/O and are reentrant code, can even be used in interrupt code and inside Disable()/Enable(). An exception to that might be functions like memcpy()/memmove(), but only for very large copies. On some systems they may be implemented using DMA, which needs to wait for the DMA operation to be completed and that might even be an IExec->Wait().
A tool like top/tequila should display CPU usage of other tasks, not cause much additional CPU usage, especially if it's without a reason like in this case
@Capehill The tasklist.c example code in the wiki is completely broken, it's using IExec->AllocVecTags() without AVT_Wait,FALSE and AVT_NoExpunge,TRUE inside Disable()! Allocating memory may require swapping out other memory and in this case the current task is suspended until that's done, which of course breaks Forbid() and Disable() states. Forbid() and Disable() states may be cancelled as well if memory handlers have to be called to free memory with the default AVT_NoExpunge,FALSE.
Why do you need task lists at all if you copy the task data, incl. the name, in the interrupt handler?
tasklist.c example code in the wiki is completely broken, it's using IExec->AllocVecTags() without AVT_Wait,FALSE and AVT_NoExpunge,TRUE inside Disable()!
Wouldn't it make sense to make AllocVecTags() itself simply auto-change it's defaults to wait=false and noexpunge if it finds itself being called by someone in forbid and/or disabled state?
Yeah, well it was a surprise to me that it's even possible to allocate memory inside Disable. Not sure why anybody wanted to.
You can call any functions inside Forbid() or Disable(), even IExec->Wait() or IDOS->Delay(), but using such functions will of course cancel the Forbid and/or Disable state ...
@Georg Quote:
Wouldn't it make sense to make AllocVecTags() itself simply auto-change it's defaults to wait=false and noexpunge if it finds itself being called by someone in forbid and/or disabled state?
Wouldn't it make sense to make AllocVecTags() itself simply auto-change it's defaults to wait=false and noexpunge if it finds itself being called by someone in forbid and/or disabled state?
No.
Why not. Note that I said "auto-change *defaults*". AllocVecTags() caller would still be able to override it. I know there are times/cases where one intenionally and correctly (not bug) wants to (or even has to) go into forbid/disabled state and then calls something which breaks that foribd/disabled state.
@Georg Can't get into details because of NDA, but the AmigaOS 4.x ExecSG memory system doesn't have anything in common with the AmigaOS <= 3.y one at all. Old/obsolete functions like AllocMem()/AllocVec()/etc. don't exist any more, they are all just stubs calling AllocVecTags(). Allocating memory doesn't only need a single memory allocator like it used to be in AmigaOS <= 3.x, but two different and independent ones: Before any virtual memory allocation can be done first physical pages have to be allocated by the page allocator for it, and that's done using different algorithms and access methods (atomic check+increase PPC instructions, and mutexes).