Something weird in VirtualMachine>>#maxExternalSemaphores:

SV
Sven Van Caekenberghe
Tue, Oct 12, 2021 2:01 PM

Hi,

The ExternalSemaphoreTable is an important resource since it holds 3 Semaphores per Socket (network connection). The size of ExternalSemaphoreTable determines how many such resources can be used concurrently.

VM parameter 49 holds this limit, it is accessed by VirtualMachine>>#maxExternalSemaphores. The default for Pharo 9 seems to be 256 currently.

There is a method VirtualMachine>>#maxExternalSemaphoresSilently: that can be used to set this limit higher. This seems to work.

Now, there are some limitations here: the number must be a power of 2, higher that the one set before and lower than 64K. BTW the number of file descriptors for files and sockets is also limited by the OS for its processes.

Also, while growing the table, the Semaphores become unavailable to the VM for a very short period of time, so they could miss signals, leading to IO issues.

For this reason, it seems that the design goal was to not allow this to grow during normal use, only during startup or upfront configuration.

Now comes the weird thing: the implementation/code of VirtualMachine>>#maxExternalSemaphores:

This is the method called when the current table is too small and when it wants to grow larger than the current VirtualMachine>>#maxExternalSemaphores.

The implementation calls #maxExternalSemaphoresSilently: in a forked thread, after signalling a SystemNotification with a full explanation. But why should this be forked in the first place ?

Then in the main thread, it signals an error ! Presumably because the design goals mentioned before.

These two actions are in conflict.

All this is probably the result of well meant evolution and refactoring, but it is quite confusing.

My first idea would be: let the caller raise the error and don't try raising the limit, remove the current implementation and replace it by what is now #maxExternalSemaphoresSilently:

What do you think ?

Sven

Hi, The ExternalSemaphoreTable is an important resource since it holds 3 Semaphores per Socket (network connection). The size of ExternalSemaphoreTable determines how many such resources can be used concurrently. VM parameter 49 holds this limit, it is accessed by VirtualMachine>>#maxExternalSemaphores. The default for Pharo 9 seems to be 256 currently. There is a method VirtualMachine>>#maxExternalSemaphoresSilently: that can be used to set this limit higher. This seems to work. Now, there are some limitations here: the number must be a power of 2, higher that the one set before and lower than 64K. BTW the number of file descriptors for files and sockets is also limited by the OS for its processes. Also, while growing the table, the Semaphores become unavailable to the VM for a very short period of time, so they could miss signals, leading to IO issues. For this reason, it seems that the design goal was to not allow this to grow during normal use, only during startup or upfront configuration. Now comes the weird thing: the implementation/code of VirtualMachine>>#maxExternalSemaphores: This is the method called when the current table is too small and when it wants to grow larger than the current VirtualMachine>>#maxExternalSemaphores. The implementation calls #maxExternalSemaphoresSilently: in a forked thread, after signalling a SystemNotification with a full explanation. But why should this be forked in the first place ? Then in the main thread, it signals an error ! Presumably because the design goals mentioned before. These two actions are in conflict. All this is probably the result of well meant evolution and refactoring, but it is quite confusing. My first idea would be: let the caller raise the error and don't try raising the limit, remove the current implementation and replace it by what is now #maxExternalSemaphoresSilently: What do you think ? Sven
HS
Henrik Sperre Johansen
Tue, Oct 12, 2021 4:55 PM

Hi Sven - you’re correct the main intent was to make it clear one should not really be setting this from the image during runtime - and make it as obvious as possible when it had.

The way I remember it, the Error was only raised if the image is in development mode - so a developer running into this, would have the limit raised, but also get a debugger (which is hard to ignore) explaining the issue, while in runtime mode, the SystemNotification would get handled by logging so it would at least be possible to spot that it had happened.

If there’s a less confusing way to achieve that it would be a good thing, but I’m not sure removing all warnings would be the best way, as the related i/o problems would be nearly impossible to determine the root cause of.

Why forked? No idea/can’t remember…

Cheers,
Henry

On 12 Oct 2021, at 16:01, Sven Van Caekenberghe sven@stfx.eu wrote:

Hi,

The ExternalSemaphoreTable is an important resource since it holds 3 Semaphores per Socket (network connection). The size of ExternalSemaphoreTable determines how many such resources can be used concurrently.

VM parameter 49 holds this limit, it is accessed by VirtualMachine>>#maxExternalSemaphores. The default for Pharo 9 seems to be 256 currently.

There is a method VirtualMachine>>#maxExternalSemaphoresSilently: that can be used to set this limit higher. This seems to work.

Now, there are some limitations here: the number must be a power of 2, higher that the one set before and lower than 64K. BTW the number of file descriptors for files and sockets is also limited by the OS for its processes.

Also, while growing the table, the Semaphores become unavailable to the VM for a very short period of time, so they could miss signals, leading to IO issues.

For this reason, it seems that the design goal was to not allow this to grow during normal use, only during startup or upfront configuration.

Now comes the weird thing: the implementation/code of VirtualMachine>>#maxExternalSemaphores:

This is the method called when the current table is too small and when it wants to grow larger than the current VirtualMachine>>#maxExternalSemaphores.

The implementation calls #maxExternalSemaphoresSilently: in a forked thread, after signalling a SystemNotification with a full explanation. But why should this be forked in the first place ?

Then in the main thread, it signals an error ! Presumably because the design goals mentioned before.

These two actions are in conflict.

All this is probably the result of well meant evolution and refactoring, but it is quite confusing.

My first idea would be: let the caller raise the error and don't try raising the limit, remove the current implementation and replace it by what is now #maxExternalSemaphoresSilently:

What do you think ?

Sven

Hi Sven - you’re correct the main intent was to make it clear one should not really be setting this from the image during runtime - and make it as obvious as possible when it had. The way I remember it, the Error was only raised if the image is in development mode - so a developer running into this, would have the limit raised, but also get a debugger (which is hard to ignore) explaining the issue, while in runtime mode, the SystemNotification would get handled by logging so it would at least be possible to spot that it had happened. If there’s a less confusing way to achieve that it would be a good thing, but I’m not sure removing all warnings would be the best way, as the related i/o problems would be nearly impossible to determine the root cause of. Why forked? No idea/can’t remember… Cheers, Henry > On 12 Oct 2021, at 16:01, Sven Van Caekenberghe <sven@stfx.eu> wrote: > > Hi, > > The ExternalSemaphoreTable is an important resource since it holds 3 Semaphores per Socket (network connection). The size of ExternalSemaphoreTable determines how many such resources can be used concurrently. > > VM parameter 49 holds this limit, it is accessed by VirtualMachine>>#maxExternalSemaphores. The default for Pharo 9 seems to be 256 currently. > > There is a method VirtualMachine>>#maxExternalSemaphoresSilently: that can be used to set this limit higher. This seems to work. > > Now, there are some limitations here: the number must be a power of 2, higher that the one set before and lower than 64K. BTW the number of file descriptors for files and sockets is also limited by the OS for its processes. > > Also, while growing the table, the Semaphores become unavailable to the VM for a very short period of time, so they could miss signals, leading to IO issues. > > For this reason, it seems that the design goal was to not allow this to grow during normal use, only during startup or upfront configuration. > > Now comes the weird thing: the implementation/code of VirtualMachine>>#maxExternalSemaphores: > > This is the method called when the current table is too small and when it wants to grow larger than the current VirtualMachine>>#maxExternalSemaphores. > > The implementation calls #maxExternalSemaphoresSilently: in a forked thread, after signalling a SystemNotification with a full explanation. But why should this be forked in the first place ? > > Then in the main thread, it signals an error ! Presumably because the design goals mentioned before. > > These two actions are in conflict. > > All this is probably the result of well meant evolution and refactoring, but it is quite confusing. > > My first idea would be: let the caller raise the error and don't try raising the limit, remove the current implementation and replace it by what is now #maxExternalSemaphoresSilently: > > What do you think ? > > Sven > > > >
HS
Henrik Sperre Johansen
Tue, Oct 12, 2021 5:20 PM

I believe Igor Stasenko made changes so signals could no longer get lost, but I’m not sure it ever got integrated in Cog…

https://forum.world.st/Issue-5965-in-pharo-Can-t-allocate-semaphores-VirtualMachine-maxExternalSemaphores-aSize-Not-enough--tp4631607p4632388.html

Maybe worth revisiting/reviewing?
If it works, the limitation would be gone, and the image warnings could be removed with no ill side-effects.

Cheers,
Henry

On 12 Oct 2021, at 18:55, Henrik Sperre Johansen henrik.s.johansen@veloxit.no wrote:

Hi Sven - you’re correct the main intent was to make it clear one should not really be setting this from the image during runtime - and make it as obvious as possible when it had.

The way I remember it, the Error was only raised if the image is in development mode - so a developer running into this, would have the limit raised, but also get a debugger (which is hard to ignore) explaining the issue, while in runtime mode, the SystemNotification would get handled by logging so it would at least be possible to spot that it had happened.

If there’s a less confusing way to achieve that it would be a good thing, but I’m not sure removing all warnings would be the best way, as the related i/o problems would be nearly impossible to determine the root cause of.

Why forked? No idea/can’t remember…

Cheers,
Henry

On 12 Oct 2021, at 16:01, Sven Van Caekenberghe sven@stfx.eu wrote:

Hi,

The ExternalSemaphoreTable is an important resource since it holds 3 Semaphores per Socket (network connection). The size of ExternalSemaphoreTable determines how many such resources can be used concurrently.

VM parameter 49 holds this limit, it is accessed by VirtualMachine>>#maxExternalSemaphores. The default for Pharo 9 seems to be 256 currently.

There is a method VirtualMachine>>#maxExternalSemaphoresSilently: that can be used to set this limit higher. This seems to work.

Now, there are some limitations here: the number must be a power of 2, higher that the one set before and lower than 64K. BTW the number of file descriptors for files and sockets is also limited by the OS for its processes.

Also, while growing the table, the Semaphores become unavailable to the VM for a very short period of time, so they could miss signals, leading to IO issues.

For this reason, it seems that the design goal was to not allow this to grow during normal use, only during startup or upfront configuration.

Now comes the weird thing: the implementation/code of VirtualMachine>>#maxExternalSemaphores:

This is the method called when the current table is too small and when it wants to grow larger than the current VirtualMachine>>#maxExternalSemaphores.

The implementation calls #maxExternalSemaphoresSilently: in a forked thread, after signalling a SystemNotification with a full explanation. But why should this be forked in the first place ?

Then in the main thread, it signals an error ! Presumably because the design goals mentioned before.

These two actions are in conflict.

All this is probably the result of well meant evolution and refactoring, but it is quite confusing.

My first idea would be: let the caller raise the error and don't try raising the limit, remove the current implementation and replace it by what is now #maxExternalSemaphoresSilently:

What do you think ?

Sven

I believe Igor Stasenko made changes so signals could no longer get lost, but I’m not sure it ever got integrated in Cog… https://forum.world.st/Issue-5965-in-pharo-Can-t-allocate-semaphores-VirtualMachine-maxExternalSemaphores-aSize-Not-enough--tp4631607p4632388.html Maybe worth revisiting/reviewing? If it works, the limitation would be gone, and the image warnings could be removed with no ill side-effects. Cheers, Henry > On 12 Oct 2021, at 18:55, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: > > Hi Sven - you’re correct the main intent was to make it clear one should not really be setting this from the image during runtime - and make it as obvious as possible when it had. > > The way I remember it, the Error was only raised if the image is in development mode - so a developer running into this, would have the limit raised, but also get a debugger (which is hard to ignore) explaining the issue, while in runtime mode, the SystemNotification would get handled by logging so it would at least be possible to spot that it had happened. > > If there’s a less confusing way to achieve that it would be a good thing, but I’m not sure removing all warnings would be the best way, as the related i/o problems would be nearly impossible to determine the root cause of. > > Why forked? No idea/can’t remember… > > Cheers, > Henry > >> On 12 Oct 2021, at 16:01, Sven Van Caekenberghe <sven@stfx.eu> wrote: >> >> Hi, >> >> The ExternalSemaphoreTable is an important resource since it holds 3 Semaphores per Socket (network connection). The size of ExternalSemaphoreTable determines how many such resources can be used concurrently. >> >> VM parameter 49 holds this limit, it is accessed by VirtualMachine>>#maxExternalSemaphores. The default for Pharo 9 seems to be 256 currently. >> >> There is a method VirtualMachine>>#maxExternalSemaphoresSilently: that can be used to set this limit higher. This seems to work. >> >> Now, there are some limitations here: the number must be a power of 2, higher that the one set before and lower than 64K. BTW the number of file descriptors for files and sockets is also limited by the OS for its processes. >> >> Also, while growing the table, the Semaphores become unavailable to the VM for a very short period of time, so they could miss signals, leading to IO issues. >> >> For this reason, it seems that the design goal was to not allow this to grow during normal use, only during startup or upfront configuration. >> >> Now comes the weird thing: the implementation/code of VirtualMachine>>#maxExternalSemaphores: >> >> This is the method called when the current table is too small and when it wants to grow larger than the current VirtualMachine>>#maxExternalSemaphores. >> >> The implementation calls #maxExternalSemaphoresSilently: in a forked thread, after signalling a SystemNotification with a full explanation. But why should this be forked in the first place ? >> >> Then in the main thread, it signals an error ! Presumably because the design goals mentioned before. >> >> These two actions are in conflict. >> >> All this is probably the result of well meant evolution and refactoring, but it is quite confusing. >> >> My first idea would be: let the caller raise the error and don't try raising the limit, remove the current implementation and replace it by what is now #maxExternalSemaphoresSilently: >> >> What do you think ? >> >> Sven >> >> >> >>
SV
Sven Van Caekenberghe
Wed, Oct 13, 2021 9:50 AM

Hi Henry,

Thanks for your reply.

I created an issue: https://github.com/pharo-project/pharo/issues/10156

Can we still find the file 'sqExternalSemaphores.c' from the old emails ?

Sven

On 12 Oct 2021, at 19:20, Henrik Sperre Johansen henrik.s.johansen@veloxit.no wrote:

I believe Igor Stasenko made changes so signals could no longer get lost, but I’m not sure it ever got integrated in Cog…

https://forum.world.st/Issue-5965-in-pharo-Can-t-allocate-semaphores-VirtualMachine-maxExternalSemaphores-aSize-Not-enough--tp4631607p4632388.html

Maybe worth revisiting/reviewing?
If it works, the limitation would be gone, and the image warnings could be removed with no ill side-effects.

Cheers,
Henry

On 12 Oct 2021, at 18:55, Henrik Sperre Johansen henrik.s.johansen@veloxit.no wrote:

Hi Sven - you’re correct the main intent was to make it clear one should not really be setting this from the image during runtime - and make it as obvious as possible when it had.

The way I remember it, the Error was only raised if the image is in development mode - so a developer running into this, would have the limit raised, but also get a debugger (which is hard to ignore) explaining the issue, while in runtime mode, the SystemNotification would get handled by logging so it would at least be possible to spot that it had happened.

If there’s a less confusing way to achieve that it would be a good thing, but I’m not sure removing all warnings would be the best way, as the related i/o problems would be nearly impossible to determine the root cause of.

Why forked? No idea/can’t remember…

Cheers,
Henry

On 12 Oct 2021, at 16:01, Sven Van Caekenberghe sven@stfx.eu wrote:

Hi,

The ExternalSemaphoreTable is an important resource since it holds 3 Semaphores per Socket (network connection). The size of ExternalSemaphoreTable determines how many such resources can be used concurrently.

VM parameter 49 holds this limit, it is accessed by VirtualMachine>>#maxExternalSemaphores. The default for Pharo 9 seems to be 256 currently.

There is a method VirtualMachine>>#maxExternalSemaphoresSilently: that can be used to set this limit higher. This seems to work.

Now, there are some limitations here: the number must be a power of 2, higher that the one set before and lower than 64K. BTW the number of file descriptors for files and sockets is also limited by the OS for its processes.

Also, while growing the table, the Semaphores become unavailable to the VM for a very short period of time, so they could miss signals, leading to IO issues.

For this reason, it seems that the design goal was to not allow this to grow during normal use, only during startup or upfront configuration.

Now comes the weird thing: the implementation/code of VirtualMachine>>#maxExternalSemaphores:

This is the method called when the current table is too small and when it wants to grow larger than the current VirtualMachine>>#maxExternalSemaphores.

The implementation calls #maxExternalSemaphoresSilently: in a forked thread, after signalling a SystemNotification with a full explanation. But why should this be forked in the first place ?

Then in the main thread, it signals an error ! Presumably because the design goals mentioned before.

These two actions are in conflict.

All this is probably the result of well meant evolution and refactoring, but it is quite confusing.

My first idea would be: let the caller raise the error and don't try raising the limit, remove the current implementation and replace it by what is now #maxExternalSemaphoresSilently:

What do you think ?

Sven

Hi Henry, Thanks for your reply. I created an issue: https://github.com/pharo-project/pharo/issues/10156 Can we still find the file 'sqExternalSemaphores.c' from the old emails ? Sven > On 12 Oct 2021, at 19:20, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: > > I believe Igor Stasenko made changes so signals could no longer get lost, but I’m not sure it ever got integrated in Cog… > > https://forum.world.st/Issue-5965-in-pharo-Can-t-allocate-semaphores-VirtualMachine-maxExternalSemaphores-aSize-Not-enough--tp4631607p4632388.html > > Maybe worth revisiting/reviewing? > If it works, the limitation would be gone, and the image warnings could be removed with no ill side-effects. > > Cheers, > Henry > >> On 12 Oct 2021, at 18:55, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: >> >> Hi Sven - you’re correct the main intent was to make it clear one should not really be setting this from the image during runtime - and make it as obvious as possible when it had. >> >> The way I remember it, the Error was only raised if the image is in development mode - so a developer running into this, would have the limit raised, but also get a debugger (which is hard to ignore) explaining the issue, while in runtime mode, the SystemNotification would get handled by logging so it would at least be possible to spot that it had happened. >> >> If there’s a less confusing way to achieve that it would be a good thing, but I’m not sure removing all warnings would be the best way, as the related i/o problems would be nearly impossible to determine the root cause of. >> >> Why forked? No idea/can’t remember… >> >> Cheers, >> Henry >> >>> On 12 Oct 2021, at 16:01, Sven Van Caekenberghe <sven@stfx.eu> wrote: >>> >>> Hi, >>> >>> The ExternalSemaphoreTable is an important resource since it holds 3 Semaphores per Socket (network connection). The size of ExternalSemaphoreTable determines how many such resources can be used concurrently. >>> >>> VM parameter 49 holds this limit, it is accessed by VirtualMachine>>#maxExternalSemaphores. The default for Pharo 9 seems to be 256 currently. >>> >>> There is a method VirtualMachine>>#maxExternalSemaphoresSilently: that can be used to set this limit higher. This seems to work. >>> >>> Now, there are some limitations here: the number must be a power of 2, higher that the one set before and lower than 64K. BTW the number of file descriptors for files and sockets is also limited by the OS for its processes. >>> >>> Also, while growing the table, the Semaphores become unavailable to the VM for a very short period of time, so they could miss signals, leading to IO issues. >>> >>> For this reason, it seems that the design goal was to not allow this to grow during normal use, only during startup or upfront configuration. >>> >>> Now comes the weird thing: the implementation/code of VirtualMachine>>#maxExternalSemaphores: >>> >>> This is the method called when the current table is too small and when it wants to grow larger than the current VirtualMachine>>#maxExternalSemaphores. >>> >>> The implementation calls #maxExternalSemaphoresSilently: in a forked thread, after signalling a SystemNotification with a full explanation. But why should this be forked in the first place ? >>> >>> Then in the main thread, it signals an error ! Presumably because the design goals mentioned before. >>> >>> These two actions are in conflict. >>> >>> All this is probably the result of well meant evolution and refactoring, but it is quite confusing. >>> >>> My first idea would be: let the caller raise the error and don't try raising the limit, remove the current implementation and replace it by what is now #maxExternalSemaphoresSilently: >>> >>> What do you think ? >>> >>> Sven >>> >>> >>> >>>
HS
Henrik Sperre Johansen
Wed, Oct 13, 2021 11:29 AM

Seens it used to be in the «old» PharoVM before the reconcilliation:
https://forum.world.st/external-semaphores-again-tp4712934p4713396.html

Maybe it’s still possible to find it in the git history of the current
pharovm repository?

Cheers,
Henry

On Wednesday, October 13, 2021, Sven Van Caekenberghe sven@stfx.eu wrote:

Hi Henry,

Thanks for your reply.

I created an issue: https://github.com/pharo-project/pharo/issues/10156

Can we still find the file 'sqExternalSemaphores.c' from the old emails ?

Sven

On 12 Oct 2021, at 19:20, Henrik Sperre Johansen <

I believe Igor Stasenko made changes so signals could no longer get

lost, but I’m not sure it ever got integrated in Cog…

semaphores-VirtualMachine-maxExternalSemaphores-aSize-
Not-enough--tp4631607p4632388.html

Maybe worth revisiting/reviewing?
If it works, the limitation would be gone, and the image warnings could

be removed with no ill side-effects.

Cheers,
Henry

On 12 Oct 2021, at 18:55, Henrik Sperre Johansen <

Hi Sven - you’re correct the main intent was to make it clear one

should not really be setting this from the image during runtime - and make
it as obvious as possible when it had.

The way I remember it, the Error was only raised if the image is in

development mode - so a developer running into this, would have the limit
raised, but also get a debugger (which is hard to ignore) explaining the
issue, while in runtime mode, the SystemNotification would get handled by
logging so it would at least be possible to spot that it had happened.

If there’s a less confusing way to achieve that it would be a good

thing, but I’m not sure removing all warnings would be the best way, as the
related i/o problems would be nearly impossible to determine the root cause
of.

Why forked? No idea/can’t remember…

Cheers,
Henry

On 12 Oct 2021, at 16:01, Sven Van Caekenberghe sven@stfx.eu wrote:

Hi,

The ExternalSemaphoreTable is an important resource since it holds 3

Semaphores per Socket (network connection). The size of
ExternalSemaphoreTable determines how many such resources can be used
concurrently.

VM parameter 49 holds this limit, it is accessed by VirtualMachine>>#maxExternalSemaphores.

The default for Pharo 9 seems to be 256 currently.

There is a method VirtualMachine>>#maxExternalSemaphoresSilently:

that can be used to set this limit higher. This seems to work.

Now, there are some limitations here: the number must be a power of 2,

higher that the one set before and lower than 64K. BTW the number of file
descriptors for files and sockets is also limited by the OS for its
processes.

Also, while growing the table, the Semaphores become unavailable to

the VM for a very short period of time, so they could miss signals, leading
to IO issues.

For this reason, it seems that the design goal was to not allow this

to grow during normal use, only during startup or upfront configuration.

Now comes the weird thing: the implementation/code of VirtualMachine>>#

maxExternalSemaphores:

This is the method called when the current table is too small and when

it wants to grow larger than the current VirtualMachine>>#
maxExternalSemaphores.

The implementation calls #maxExternalSemaphoresSilently: in a forked

thread, after signalling a SystemNotification with a full explanation. But
why should this be forked in the first place ?

Then in the main thread, it signals an error ! Presumably because the

design goals mentioned before.

These two actions are in conflict.

All this is probably the result of well meant evolution and

refactoring, but it is quite confusing.

My first idea would be: let the caller raise the error and don't try

raising the limit, remove the current implementation and replace it by what
is now #maxExternalSemaphoresSilently:

What do you think ?

Sven

Seens it used to be in the «old» PharoVM before the reconcilliation: https://forum.world.st/external-semaphores-again-tp4712934p4713396.html Maybe it’s still possible to find it in the git history of the current pharovm repository? Cheers, Henry On Wednesday, October 13, 2021, Sven Van Caekenberghe <sven@stfx.eu> wrote: > Hi Henry, > > Thanks for your reply. > > I created an issue: https://github.com/pharo-project/pharo/issues/10156 > > Can we still find the file 'sqExternalSemaphores.c' from the old emails ? > > Sven > > > On 12 Oct 2021, at 19:20, Henrik Sperre Johansen < > henrik.s.johansen@veloxit.no> wrote: > > > > I believe Igor Stasenko made changes so signals could no longer get > lost, but I’m not sure it ever got integrated in Cog… > > > > https://forum.world.st/Issue-5965-in-pharo-Can-t-allocate- > semaphores-VirtualMachine-maxExternalSemaphores-aSize- > Not-enough--tp4631607p4632388.html > > > > Maybe worth revisiting/reviewing? > > If it works, the limitation would be gone, and the image warnings could > be removed with no ill side-effects. > > > > Cheers, > > Henry > > > >> On 12 Oct 2021, at 18:55, Henrik Sperre Johansen < > henrik.s.johansen@veloxit.no> wrote: > >> > >> Hi Sven - you’re correct the main intent was to make it clear one > should not really be setting this from the image during runtime - and make > it as obvious as possible when it had. > >> > >> The way I remember it, the Error was only raised if the image is in > development mode - so a developer running into this, would have the limit > raised, but also get a debugger (which is hard to ignore) explaining the > issue, while in runtime mode, the SystemNotification would get handled by > logging so it would at least be possible to spot that it had happened. > >> > >> If there’s a less confusing way to achieve that it would be a good > thing, but I’m not sure removing all warnings would be the best way, as the > related i/o problems would be nearly impossible to determine the root cause > of. > >> > >> Why forked? No idea/can’t remember… > >> > >> Cheers, > >> Henry > >> > >>> On 12 Oct 2021, at 16:01, Sven Van Caekenberghe <sven@stfx.eu> wrote: > >>> > >>> Hi, > >>> > >>> The ExternalSemaphoreTable is an important resource since it holds 3 > Semaphores per Socket (network connection). The size of > ExternalSemaphoreTable determines how many such resources can be used > concurrently. > >>> > >>> VM parameter 49 holds this limit, it is accessed by VirtualMachine>>#maxExternalSemaphores. > The default for Pharo 9 seems to be 256 currently. > >>> > >>> There is a method VirtualMachine>>#maxExternalSemaphoresSilently: > that can be used to set this limit higher. This seems to work. > >>> > >>> Now, there are some limitations here: the number must be a power of 2, > higher that the one set before and lower than 64K. BTW the number of file > descriptors for files and sockets is also limited by the OS for its > processes. > >>> > >>> Also, while growing the table, the Semaphores become unavailable to > the VM for a very short period of time, so they could miss signals, leading > to IO issues. > >>> > >>> For this reason, it seems that the design goal was to not allow this > to grow during normal use, only during startup or upfront configuration. > >>> > >>> Now comes the weird thing: the implementation/code of VirtualMachine>># > maxExternalSemaphores: > >>> > >>> This is the method called when the current table is too small and when > it wants to grow larger than the current VirtualMachine>># > maxExternalSemaphores. > >>> > >>> The implementation calls #maxExternalSemaphoresSilently: in a forked > thread, after signalling a SystemNotification with a full explanation. But > why should this be forked in the first place ? > >>> > >>> Then in the main thread, it signals an error ! Presumably because the > design goals mentioned before. > >>> > >>> These two actions are in conflict. > >>> > >>> All this is probably the result of well meant evolution and > refactoring, but it is quite confusing. > >>> > >>> My first idea would be: let the caller raise the error and don't try > raising the limit, remove the current implementation and replace it by what > is now #maxExternalSemaphoresSilently: > >>> > >>> What do you think ? > >>> > >>> Sven > >>> > >>> > >>> > >>> >
SV
Sven Van Caekenberghe
Wed, Oct 13, 2021 12:12 PM

I copied your comment to the issue thread.

Maybe it is best to hold the conversation there as to leave a better trace.

On 13 Oct 2021, at 13:29, Henrik Sperre Johansen henrik.s.johansen@veloxit.no wrote:

Seens it used to be in the «old» PharoVM before the reconcilliation:
https://forum.world.st/external-semaphores-again-tp4712934p4713396.html

Maybe it’s still possible to find it in the git history of the current pharovm repository?

Cheers,
Henry

On Wednesday, October 13, 2021, Sven Van Caekenberghe sven@stfx.eu wrote:
Hi Henry,

Thanks for your reply.

I created an issue: https://github.com/pharo-project/pharo/issues/10156

Can we still find the file 'sqExternalSemaphores.c' from the old emails ?

Sven

On 12 Oct 2021, at 19:20, Henrik Sperre Johansen henrik.s.johansen@veloxit.no wrote:

I believe Igor Stasenko made changes so signals could no longer get lost, but I’m not sure it ever got integrated in Cog…

https://forum.world.st/Issue-5965-in-pharo-Can-t-allocate-semaphores-VirtualMachine-maxExternalSemaphores-aSize-Not-enough--tp4631607p4632388.html

Maybe worth revisiting/reviewing?
If it works, the limitation would be gone, and the image warnings could be removed with no ill side-effects.

Cheers,
Henry

On 12 Oct 2021, at 18:55, Henrik Sperre Johansen henrik.s.johansen@veloxit.no wrote:

Hi Sven - you’re correct the main intent was to make it clear one should not really be setting this from the image during runtime - and make it as obvious as possible when it had.

The way I remember it, the Error was only raised if the image is in development mode - so a developer running into this, would have the limit raised, but also get a debugger (which is hard to ignore) explaining the issue, while in runtime mode, the SystemNotification would get handled by logging so it would at least be possible to spot that it had happened.

If there’s a less confusing way to achieve that it would be a good thing, but I’m not sure removing all warnings would be the best way, as the related i/o problems would be nearly impossible to determine the root cause of.

Why forked? No idea/can’t remember…

Cheers,
Henry

On 12 Oct 2021, at 16:01, Sven Van Caekenberghe sven@stfx.eu wrote:

Hi,

The ExternalSemaphoreTable is an important resource since it holds 3 Semaphores per Socket (network connection). The size of ExternalSemaphoreTable determines how many such resources can be used concurrently.

VM parameter 49 holds this limit, it is accessed by VirtualMachine>>#maxExternalSemaphores. The default for Pharo 9 seems to be 256 currently.

There is a method VirtualMachine>>#maxExternalSemaphoresSilently: that can be used to set this limit higher. This seems to work.

Now, there are some limitations here: the number must be a power of 2, higher that the one set before and lower than 64K. BTW the number of file descriptors for files and sockets is also limited by the OS for its processes.

Also, while growing the table, the Semaphores become unavailable to the VM for a very short period of time, so they could miss signals, leading to IO issues.

For this reason, it seems that the design goal was to not allow this to grow during normal use, only during startup or upfront configuration.

Now comes the weird thing: the implementation/code of VirtualMachine>>#maxExternalSemaphores:

This is the method called when the current table is too small and when it wants to grow larger than the current VirtualMachine>>#maxExternalSemaphores.

The implementation calls #maxExternalSemaphoresSilently: in a forked thread, after signalling a SystemNotification with a full explanation. But why should this be forked in the first place ?

Then in the main thread, it signals an error ! Presumably because the design goals mentioned before.

These two actions are in conflict.

All this is probably the result of well meant evolution and refactoring, but it is quite confusing.

My first idea would be: let the caller raise the error and don't try raising the limit, remove the current implementation and replace it by what is now #maxExternalSemaphoresSilently:

What do you think ?

Sven

I copied your comment to the issue thread. Maybe it is best to hold the conversation there as to leave a better trace. > On 13 Oct 2021, at 13:29, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: > > Seens it used to be in the «old» PharoVM before the reconcilliation: > https://forum.world.st/external-semaphores-again-tp4712934p4713396.html > > Maybe it’s still possible to find it in the git history of the current pharovm repository? > > Cheers, > Henry > > On Wednesday, October 13, 2021, Sven Van Caekenberghe <sven@stfx.eu> wrote: > Hi Henry, > > Thanks for your reply. > > I created an issue: https://github.com/pharo-project/pharo/issues/10156 > > Can we still find the file 'sqExternalSemaphores.c' from the old emails ? > > Sven > > > On 12 Oct 2021, at 19:20, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: > > > > I believe Igor Stasenko made changes so signals could no longer get lost, but I’m not sure it ever got integrated in Cog… > > > > https://forum.world.st/Issue-5965-in-pharo-Can-t-allocate-semaphores-VirtualMachine-maxExternalSemaphores-aSize-Not-enough--tp4631607p4632388.html > > > > Maybe worth revisiting/reviewing? > > If it works, the limitation would be gone, and the image warnings could be removed with no ill side-effects. > > > > Cheers, > > Henry > > > >> On 12 Oct 2021, at 18:55, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: > >> > >> Hi Sven - you’re correct the main intent was to make it clear one should not really be setting this from the image during runtime - and make it as obvious as possible when it had. > >> > >> The way I remember it, the Error was only raised if the image is in development mode - so a developer running into this, would have the limit raised, but also get a debugger (which is hard to ignore) explaining the issue, while in runtime mode, the SystemNotification would get handled by logging so it would at least be possible to spot that it had happened. > >> > >> If there’s a less confusing way to achieve that it would be a good thing, but I’m not sure removing all warnings would be the best way, as the related i/o problems would be nearly impossible to determine the root cause of. > >> > >> Why forked? No idea/can’t remember… > >> > >> Cheers, > >> Henry > >> > >>> On 12 Oct 2021, at 16:01, Sven Van Caekenberghe <sven@stfx.eu> wrote: > >>> > >>> Hi, > >>> > >>> The ExternalSemaphoreTable is an important resource since it holds 3 Semaphores per Socket (network connection). The size of ExternalSemaphoreTable determines how many such resources can be used concurrently. > >>> > >>> VM parameter 49 holds this limit, it is accessed by VirtualMachine>>#maxExternalSemaphores. The default for Pharo 9 seems to be 256 currently. > >>> > >>> There is a method VirtualMachine>>#maxExternalSemaphoresSilently: that can be used to set this limit higher. This seems to work. > >>> > >>> Now, there are some limitations here: the number must be a power of 2, higher that the one set before and lower than 64K. BTW the number of file descriptors for files and sockets is also limited by the OS for its processes. > >>> > >>> Also, while growing the table, the Semaphores become unavailable to the VM for a very short period of time, so they could miss signals, leading to IO issues. > >>> > >>> For this reason, it seems that the design goal was to not allow this to grow during normal use, only during startup or upfront configuration. > >>> > >>> Now comes the weird thing: the implementation/code of VirtualMachine>>#maxExternalSemaphores: > >>> > >>> This is the method called when the current table is too small and when it wants to grow larger than the current VirtualMachine>>#maxExternalSemaphores. > >>> > >>> The implementation calls #maxExternalSemaphoresSilently: in a forked thread, after signalling a SystemNotification with a full explanation. But why should this be forked in the first place ? > >>> > >>> Then in the main thread, it signals an error ! Presumably because the design goals mentioned before. > >>> > >>> These two actions are in conflict. > >>> > >>> All this is probably the result of well meant evolution and refactoring, but it is quite confusing. > >>> > >>> My first idea would be: let the caller raise the error and don't try raising the limit, remove the current implementation and replace it by what is now #maxExternalSemaphoresSilently: > >>> > >>> What do you think ? > >>> > >>> Sven > >>> > >>> > >>> > >>>