You should put Forbid()/Permit() around your list scanning code to stop ports from being added/removed while you are scanning the list and causing your program to crash.
FindPort(), AddPort() and RemPort() functions all use Forbid() based locking. If your program uses some other method then it is broken.
Also you should keep in mind restrictions when in Forbid() state. That is:
1. Don't call Wait() or anything that will indirectly call Wait() (this includes AllocVecTags() if AVT_Wait is left at it's default value and anything that involves file I/O, mutexes or semaphores) as this will break the program's Forbid() state.
2. Do what needs to be done as quickly as possible and don't waste any time.
If you need to copy data from the list then I suggest allocating a large enough buffer beforehand and using that. If it turns out that your estimated buffer size was too small you can allocate a bigger one and begin the scan again.
"If your program uses some other method then it is broken."
Yes, i know, i wonder everyday why it doesn't crash more often ;)
More seriously, i thought that Forbid() have to be avoided for an eventual future and have to be replaced by Mutex.
If it's not true, what is the rule ?
"If your program uses some other method then it is broken."
Yes, i know, i wonder everyday why it doesn't crash more often ;)
Luck :-)
More seriously, i thought that Forbid() have to be avoided for an eventual future and have to be replaced by Mutex.
If it's not true, what is the rule ?
You can only replace a forbid / permit pair with a mutex or semaphore when all processes accessing the data you want to protect know about the mutetx / semaphore.
So for your own new programs that share data between multiple processes than using amutex or semaphore is far better than forbid / permit (and that's not really a new guideline) but for accessing pubic data structure like the port list then there must be a public mutext or semaphore to arbitrate access, and as far as I know there isn't one for the port list. One can't be added easily as so many old prgranms are using Forbid/Permit pairs to access the Port List.
That makes me wander exactly what mutex you were obtaining in your program.
Ah ok, thank you, therefore i have to revert all my Mutex to Forbid.
I don't know which Mutex I obtained, but as you said i should be lucky to don't have crash (nobody reported crashs about that in SysMon or FastCompress where I use FindPort, maybe simply because no amigans use them ;) )
I do like that in SysMon Ports tab
Nice! Thank you!
I had to update one line to this:
struct List *execPortlist = &(((struct ExecBase *)SysBase)->PortList);
You should put Forbid()/Permit() around your list scanning code to stop ports from being added/removed while you are scanning the list and causing your program to crash.
@Salass00
In my program, SysMon, I use MutexObtain / MutexRelease instead of Forbid / Permit to lock the PortList.
What is the best method ? Are all the Forbid / Permit have to be transformed in MutexObtain / MutexRelease ?
Thank you for your advices.
@zzd10h
FindPort(), AddPort() and RemPort() functions all use Forbid() based locking. If your program uses some other method then it is broken.
Also you should keep in mind restrictions when in Forbid() state. That is:
1. Don't call Wait() or anything that will indirectly call Wait() (this includes AllocVecTags() if AVT_Wait is left at it's default value and anything that involves file I/O, mutexes or semaphores) as this will break the program's Forbid() state.
2. Do what needs to be done as quickly as possible and don't waste any time.
If you need to copy data from the list then I suggest allocating a large enough buffer beforehand and using that. If it turns out that your estimated buffer size was too small you can allocate a bigger one and begin the scan again.
"If your program uses some other method then it is broken."
Yes, i know, i wonder everyday why it doesn't crash more often ;)
More seriously, i thought that Forbid() have to be avoided for an eventual future and have to be replaced by Mutex.
If it's not true, what is the rule ?
Thanks
Luck :-)
You can only replace a forbid / permit pair with a mutex or semaphore when all processes accessing the data you want to protect know about the mutetx / semaphore.
So for your own new programs that share data between multiple processes than using amutex or semaphore is far better than forbid / permit (and that's not really a new guideline) but for accessing pubic data structure like the port list then there must be a public mutext or semaphore to arbitrate access, and as far as I know there isn't one for the port list. One can't be added easily as so many old prgranms are using Forbid/Permit pairs to access the Port List.
That makes me wander exactly what mutex you were obtaining in your program.
Ah ok, thank you, therefore i have to revert all my Mutex to Forbid.
I don't know which Mutex I obtained, but as you said i should be lucky to don't have crash (nobody reported crashs about that in SysMon or FastCompress where I use FindPort, maybe simply because no amigans use them ;) )
Sorry for the offtopic, mritter.
Not a problem at all. I am still learning new OS4 stuff all the time.