On 8 October 2013 22:03, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Igor,

On Tue, Oct 8, 2013 at 2:27 AM, Igor Stasenko <siguctua@gmail.com> wrote:

On 7 October 2013 18:36, Norbert Hartl <norbert@hartl.name> wrote:

Am 07.10.2013 um 16:36 schrieb Igor Stasenko <siguctua@gmail.com>:

1 thing.

can you tell me what given expression yields for your VM/image:

Smalltalk vm maxExternalSemaphores

(if it gives you number less than 10000000 then i think i know what is your problem :)

It is��10000000

What would be the problem if it would be smaller?

that just means your VM don't have external object size cap.

I changed the implementation to not have hard limit (the arbitrary large number
is there just to be "compatible" with previous implementation).

If you've really done this why haven't you pushed changes back to me? ��You think I like the limit ?!? ;-). ��But is your new implementation lock-free? ��I went to some lengths to make sure that the Cog implementation is thread-safe, by making signalling lock-free. ��But making it lock-free while allowing growing was too much work. ��If your new implementation isn't lock-free and/or isn't thread-safe then IMO the cure is worse than the disease, because signals can get lost and that's much harder to diagnose than deal with a limit that can only be set at startup.

I understand your concerns. And inviting you to verify my implementation.
It should be lock-free and thread-safe.

All changes are in single file, so you can just take it and replace existing one..
https://github.com/pharo-project/pharo-vm/blob/master/platforms/Cross/vm/sqExternalSemaphores.c

should be easy to pick up for you.

If you don't remember, in short, i changed the way to it works, by accumulating signals into static-sized buffer,

which then flushed upon each interrupt.

As long as time between two interrupts remain relatively small, it is highly improbable that this buffer
will be overrun.

--
Best regards,
Igor Stasenko.