[LRUG] Fwd: basic actor library

[Ben Lovell]

I've just noticed Nick and I have had this whole conversation in private. I
know there were reasons, but it still doesn't stop me forgetting that LRUG
is the only instance in the known universe to reply off-list by default.

Cheers,
Ben

---------- Forwarded message ----------
From: Ben Lovell <benjamin.lovell at gmail.com>
Date: 7 June 2013 13:07
Subject: Re: [LRUG] basic actor library
To: Nick Griffiths <nicobrevin at gmail.com>


On 7 June 2013 12:26, Nick Griffiths <nicobrevin at gmail.com> wrote:

> On 7 June 2013 12:00, Ben Lovell <benjamin.lovell at gmail.com> wrote:
>
>> On 7 June 2013 11:49, Nick Griffiths <nicobrevin at gmail.com> wrote:
>>
>>> On 7 June 2013 11:36, Ben Lovell <benjamin.lovell at gmail.com> wrote:
>>>
>>>> On 7 June 2013 11:30, Nick Griffiths <nicobrevin at gmail.com> wrote:
>>>>
>>>>> Hi list,
>>>>>
>>>>> I'm looking for a simple actor library that just does the whole 'give
>>>>> a thread a mailbox' thing so that I can give some objects an event loop, so
>>>>> I don't have to piss around with locks.
>>>>>
>>>>> There is celluloid, but it looks like it is a lot more than I need.  I
>>>>> was hoping there was something a bit smaller, or maybe celluloid is as
>>>>> small as it comes.
>>>>>
>>>>
>>>> Celluloid has a fairly minor mental footprint if you're just interested
>>>> in the simple actor aspects. One thing to remember however is that
>>>> celluloid is an *abstraction* over the actor model rather than a pure
>>>> implementation.
>>>>
>>>
>>> Thanks Ben, that is a nice summary.  I'm willing to give it a go, but
>>> yeah, I was hoping to get a bit closer to the guts of it.
>>>
>>>
>>>> Rubinius actors are probably what you're looking for in terms of
>>>> purity: http://rubini.us/doc/en/systems/concurrency/
>>>>
>>>
>>> But I'm guessing you need to run it on rubinius - looks like someone has
>>> tried to port it to MRI [1] as part of a bigger project, but no idea how
>>> tested or supported that is...
>>>
>>>
>> Yes, that is obviously restricted to rubinius. You've also got revactor
>> [0] which predates celluloid and is also a Tony Arcieri creation (tm). This
>> may serve as some inspiration.
>>
>> Regardless, if your actors are intended to be threaded you'll most likely
>> want to look to a non-GIL constrained VM if you're planning on doing mostly
>> computation.
>>
>> Are you doing this purely for experimentation or anything meaningful?
>> (Not that the former precludes the latter)
>>
>
> We've got a little continuous deployment tool [1] that watches a build
> directory for new packages and stuffs them in to our apt repository based
> on some versioning rules.  It's a bit incomplete at the moment, and as part
> of finishing off some of the features I thought I'd tighten up the threaded
> code - a good chance to experiment with using actors for locking, rather
> than just doing it the old school mutex route (which I'm comfortable with,
> but it just isn't hip anymore, is it?).
>
> So no need for true multi-threading, no need for massive throughput, I
> just want to make access to some resources and types of operation
> sequential for safety and sanity reasons.  This is why I had shied away
> from celluloid - seemed like overkill.
>
>
Interesting. I was also reminded of a practicing ruby article [0] that had
a succinct actors implementation. May well be useful...

[0] https://practicingruby.com/articles/shared/nkhaprcgwrpv

Cheers,
Ben


> ---
>
> [1] - https://github.com/playlouder/apt_control
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130607/af3c7258/attachment-0003.html>