Re: [Gc] STW usage of signals

Hi Ivan,

I haven't measured the overhead of sigsuspend compared to semaphores.
I would expect the change to be measurable only on very tiny heaps with
lots of threads.

The change will be done against mono's GC, which is LGPL, but I see about
dual licensing
it so if you guys want to use it, you'll be able to.

For the targets we work on, semaphores are async safe. It's a subset of
what bdw supports, but
I'd be surprised if an OS didn't make them so.

--
Rodrigo




On Tue, Nov 11, 2014 at 3:20 AM, Ivan Maidanski <ivmai-JGs/[email protected]> wrote:

> Hi Rodrigo,
>
> Some time ago I thought about reducing of number of signals used by GC. It
> should be possible to use same signal for suspend and resume but it seems
> to add some overhead.
>
> If you have some code enabling signal reuse/multiplexing - you are welcome.
>
> Regards,
> Ivan
>
> --
>
> Mon 10 Nov 2014, 23:19 +03:00 from Hans Boehm <[email protected]>:
>
> IIRC, the main issue is that sigsuspend is specified to be
> async-signal-safe, while sem_wait is not.
>
> Hans
>
> On Sat, Nov 8, 2014 at 9:16 AM, Rodrigo Kumpera  < [email protected] >
> wrote:
> >Hey Guys,
> >The mono VM is running short of usable signals on some targets and we're
> going to do signal multiplexing.
> >We use the same signal based suspend/resume mechanism as bdwgc and I've
> been wondering on why sigwait was used instead of a semaphore to implement
> resume.
> >This decision was made way way in the past but maybe someone still
> remember the rationale for it?
> >--
> >Rodrigo
> >_______________________________________________
> >bdwgc mailing list
> >[email protected]
> >https://lists.opendylan.org/mailman/listinfo/bdwgc
>
> _______________________________________________
> bdwgc mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/bdwgc
>

_______________________________________________
bdwgc mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/bdwgc