Doesn't std.signal completely miss the point?

[Johannes Pfau]

Andrej Mitrovic wrote:
>On 9/5/11, Johannes Pfau <spam at example.com> wrote:
>> You're talking about phobos std.signals, not my implementation,
>> right?
>
>Yes.
>
>On 9/5/11, Johannes Pfau <spam at example.com> wrote:
>> However, I think it's useless as long as it can't be used by multiple
>> threads. But when I wanted to add 'shared' support to it, I always
>> hit a dead end, a bug, something not working, so in the end I gave
>> up.
>
>I'm not really sure how multithreading should work with signals (well
>I'm just too new to multithreading anyways). Some people have
>mentioned that DFL is thread-friendly, but I'm not seeing any
>synchronization in its Event type, whereas DGUI has a synchronized()
>block around the code that invokes signal handlers.
>
>> Another point which could be improved is that it currently only works
>> for @safe/@trusted delegates. Maybe a @system signal is also useful.
>
>Why must they be @safe?

There's no technical reason. But as soon as one @system delegate is
connected, emit() must also be @system. But if emit() is @system you
can't emit events from safeD code. So currently emit() is @trusted to
support safeD and all connected delegates should be @safe or @trusted.
In the end it should be possible to choose between a @safe and a @system
signal though.

-- 
Johannes Pfau