Hyperion Entertainment Message Boards

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.

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.

@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?

trixie wrote:How's MorphOS with signals, does anybody know?

Itix has obviously spotted this and helpfully provided an answer: http://amigaworld.net/modules/newbb/vie ... 3&forum=15

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.

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).

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.

@chris

window.class (shared message post, so only one for all windows)

Two if you support iconification - the AppPort uses a signal as well.

I haven't even registered with commodities.library

NetSurf is not a commodity-type program; why would you want to register with commodities.library?

trixie wrote:@chris

window.class (shared message post, so only one for all windows)

Two if you support iconification - the AppPort uses a signal as well.

I don't... well, I do, but that's all tied in with the WB AppMessages.

NetSurf is not a commodity-type program; why would you want to register with commodities.library?

I wouldn't, I just meant there was a possibility for using up even more 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.

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

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.

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.

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

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.

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?