Currently, OS4 has 32 signals - 16 of which are reserved for the OS, leaving 16 for applications.
With the advent of new features, only having sixteen signals available for use is getting increasingly restrictive:
Create a message port, you need a signal.
Register with application.library, you need a signal.
Open a context menu, you need a signal.
Set a timer, you need a signal.
In fact, notification of any event needs a signal.
Whilst some of these can be freed and re-used, the majority of signals are allocated at program launch (usually indirectly, by creating message ports or using some library allocation function), and not freed until the program exits.
Please can the number of available signals be increased?
I envisage using a 64-bit (or longer) value for the signal bit mask passed to a new Wait64() function, and a new AllocSignal64() to allocate signals both in the old and new range (but, like the existing one, starting at the high end - this allows legacy libraries/functions more breathing space in the 16-31 range). This would give an additional 32 signals for applications to use without requiring major changes to event loops - although I can see potential problems with "old" functions still having to allocate from the 32-bit pool (for compatibility), if new applications could harness the extra bits for directly-allocated signals and message ports that would be a good start.
Increase number of available signals
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: Increase number of available signals
We have talked about this problem in the past on the developer ML. We all agreed that we need to go to a 64-bit signal word, but so far it has not been tried.
I'll stoke the fire a bit.
I'll stoke the fire a bit.
cheers
tony
tony
Re: Increase number of available signals
@chris, tonyw
I agree - this is something that should leave the back burner quite soon IMHO. 16 signals is a 1980s legacy, and a complex modern application like NetSurf can eat them up easily. Rather than make the programmer resort to various dirty tricks it's better to think of a general solution.
How's MorphOS with signals, does anybody know?
I agree - this is something that should leave the back burner quite soon IMHO. 16 signals is a 1980s legacy, and a complex modern application like NetSurf can eat them up easily. Rather than make the programmer resort to various dirty tricks it's better to think of a general solution.
How's MorphOS with signals, does anybody know?
The Rear Window blog
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
Re: Increase number of available signals
Itix has obviously spotted this and helpfully provided an answer: http://amigaworld.net/modules/newbb/vie ... 3&forum=15trixie wrote:How's MorphOS with signals, does anybody know?
I don't think spawning new processes to get around this ancient limitation is really a solution (and probably not even possible in a lot of cases).On MorphOS there are 15 signals allocatable by user application and 17 allocated by operating system. This is less than in AmigaOS because one user signal is allocated to task message port but this port can be used internally for whatever purpose developer wants to.
In my opinion 16 signals is enough. I dont remember ever running out of signal bits and if you do you can always restructure your application to use less signals or spawn new processes to have more signals available.
btw, the reason NetSurf uses so many is:
window.class (shared message post, so only one for all windows)
timer.device
libpthreads
AmigaGuide
popupmenu
public screen closure notification
application.library
WB AppMessages
ARexx
(something to do with printing, which I'm not using currently)
That's 10, I'm not sure what the others have been allocated for but I was right up to the limit, and I don't think that's a particularly unusual list of requirements (there are just more than most people would need, and I haven't even registered with commodities.library).
I think AmiDock has a similar problem given the popupmenu crashes were being seen there too.
Re: Increase number of available signals
@chris
Two if you support iconification - the AppPort uses a signal as well.window.class (shared message post, so only one for all windows)
NetSurf is not a commodity-type program; why would you want to register with commodities.library?I haven't even registered with commodities.library
The Rear Window blog
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
Re: Increase number of available signals
I don't... well, I do, but that's all tied in with the WB AppMessages.trixie wrote:@chris
Two if you support iconification - the AppPort uses a signal as well.window.class (shared message post, so only one for all windows)
I wouldn't, I just meant there was a possibility for using up even more signals.NetSurf is not a commodity-type program; why would you want to register with commodities.library?
Re: Increase number of available signals
I think that itix is right, and if system components that are in the end tied to window.class eat up so many signals, it´s time to restructure some of the system´s components (e.g. context menus, appmessages, screen notification, application library and I bet there are some more).
But if we look at it the other way, NetSurf is quite a big thing and it still doesn´t munch ALL of the available signals per task. The solution to use child tasks/processes for some operations isn´t as bad as it sounds, as there are indeed lots of cases where a separation makes sense. This might not be easy for "portable" software like NetSurf, Odyssey and whatnot, but that´s a different story.
Please don´t open just another construction site just because software development outside the Amiga gets more and more resource hungry (unnecessarily, most of the time). There´s enough work to do with SMP, 64 bit processing, bug squashing, improvement of, ermh, suboptimal system components etc. etc.
But if we look at it the other way, NetSurf is quite a big thing and it still doesn´t munch ALL of the available signals per task. The solution to use child tasks/processes for some operations isn´t as bad as it sounds, as there are indeed lots of cases where a separation makes sense. This might not be easy for "portable" software like NetSurf, Odyssey and whatnot, but that´s a different story.
Please don´t open just another construction site just because software development outside the Amiga gets more and more resource hungry (unnecessarily, most of the time). There´s enough work to do with SMP, 64 bit processing, bug squashing, improvement of, ermh, suboptimal system components etc. etc.
- broadblues
- AmigaOS Core Developer
- Posts: 600
- Joined: Sat Jun 18, 2011 2:40 am
- Location: Portsmouth, UK
- Contact:
Re: Increase number of available signals
Surely some of these signals can be shared? Is there any reason apart from habit that two ports needs two seperate signals? You can certainly specify the signal when creating a port using ASOPORT_Signal.window.class (shared message post, so only one for all windows)
timer.device
libpthreads
AmigaGuide
popupmenu
public screen closure notification
application.library
WB AppMessages
ARexx
Re: Increase number of available signals
I looked into that, but I'm only actually creating two of these message ports myself, the rest are allocated internally by various initialisation functions.broadblues wrote: Surely some of these signals can be shared? Is there any reason apart from habit that two ports needs two seperate signals? You can certainly specify the signal when creating a port using ASOPORT_Signal.
Re: Increase number of available signals
@broadblues
Event identification perhaps. If I create the window AppPort with ASOPORT_Signal pointing to the window UserPort's signal, how do I distinguish between IDCMP messages and appmessages arriving now all at the same port?Is there any reason apart from habit that two ports needs two seperate signals? You can certainly specify the signal when creating a port using ASOPORT_Signal.
The Rear Window blog
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition