Ayende @ Rahien

Ayende Rahien commented on A minimal actor framework

Fri, 13 May 2011 07:54:43 GMT

Johannes, Yes, we didn't have guids for posts, so it did that. Fixed now

Johannes Hansen commented on A minimal actor framework

Fri, 13 May 2011 07:52:18 GMT

Hi Ayende, everytime you've posted a message lately my google reader has marked ALL your previous posts as new posts as well. There might be something wrong with your blog engine. Just letting you know. :)

Ayende Rahien commented on A minimal actor framework

Thu, 05 May 2011 14:12:00 GMT

Michael, Take a look at the next post

Michael Reichenauer commented on A minimal actor framework

Thu, 05 May 2011 11:07:21 GMT

Skip/delete my previous comment, I failed to notice that this was already covered in your next post

Michael Reichenauer commented on A minimal actor framework

Thu, 05 May 2011 09:44:35 GMT

A problem with using Task.Factory.StartNew(action) is that a pool thread is blocked while an action running. For a single Actor in a program, this is not a big problem (only one thread from the pool), but if there would be multiple Actors running concurrently, it could become a real problem, if the actions might block for some time. A different approach (but a bit more complicated and restricted) would be to let the Actor handle the sequential scheduling of provided async operations: Act(Func action) I.e. the caller queues delegates, which returns a Task. The Act function just ensures that each scheduled Task continues with the next. It is not possible to queue Task directly (skipping the delegate), since that would force callers to Start task at the time of the call to Act(). The delegate allows Act() to trigger the async operation when the previous Task is done. The caller can implement efficient async operations, which do not block threads, e.g. by using Task.FromAsync() on BeginX/EndX functions and use the Actor to have them run in sequence. The caller can still queue inefficient blocking tasks when only sync operations are available.

x4m commented on A minimal actor framework

Thu, 05 May 2011 08:42:57 GMT

Thread1 is doing private void ExecuteActions() { Action

x4m commented on A minimal actor framework

Thu, 05 May 2011 08:31:38 GMT

One action can hold not runned, because you acquire lock after testing queue is empty in ExecuteActions()

Anthony commented on A minimal actor framework

Wed, 04 May 2011 18:27:52 GMT

Retlang is a great, simple framework to handle this kind of thing: [http://code.google.com/p/retlang/](http://code.google.com/p/retlang/)

Rabo commented on A minimal actor framework

Wed, 04 May 2011 15:47:53 GMT

I'd improve it by writing it in F# as a MailboxProcessor. I guess Colin already mentioned this, but it would require hardly any code and would be perfectly suited to such a task.

Rafal commented on A minimal actor framework

Wed, 04 May 2011 12:56:05 GMT

You have no error handling

Oğuzhan Eren commented on A minimal actor framework

Wed, 04 May 2011 12:28:38 GMT

"actions.Enqueue(action);" process should be separete Act function so I will be add action to Queue any time (working actor)

Colin commented on A minimal actor framework

Wed, 04 May 2011 12:23:50 GMT

Have you considered wrapping the MailboxProcessor<'a> from the FSharp Control primitives in a C# friendly type with the API you wish to define. I have done this in the project I am currently working on and it works well, although it puts a dependency on Fsharp.Core something you may wish to avoid

Mayrc Mellow commented on A minimal actor framework

Wed, 04 May 2011 12:03:06 GMT

I see a problem: if I call Act method and activeTask object isn't null, the task that I'm adding only will execute on next time that I call Act method again. Is this a problem?

Ayende Rahien commented on A minimal actor framework

Wed, 04 May 2011 10:42:44 GMT

Sam, No, one after another

Sam Leitch commented on A minimal actor framework

Wed, 04 May 2011 10:34:49 GMT

By synchronous, so you mean each action has to execute in the same thread? If that's the case then...well... there are problems. StartNew is not guaranteed to use the same thread twice.

Sam Leitch commented on A minimal actor framework

Wed, 04 May 2011 10:24:25 GMT

You would need a SchedulerPair per "actor". Each ExclusiveScheduler can run in parallel (at least I hope so). I see it as a non-blocking form of reader/writer lock. It doesn't ensure in-order processing though. Only that each task will run on its own.

Ayende Rahien commented on A minimal actor framework

Wed, 04 May 2011 10:18:37 GMT

Sam, That means that everything in sync, but I want parallelism between different actors.

Sam Leitch commented on A minimal actor framework

Wed, 04 May 2011 10:14:55 GMT

Have you taken a look at the ConcurrentExclusiveSchedulerPair included in TPL Dataflow? It provides the same synchronization of tasks but doesn't break the task/continuation pattern. Just schedule everything on the ExclusiveScheduler and you're good to go.

Scooletz commented on A minimal actor framework

Wed, 04 May 2011 10:03:57 GMT

How about having one ConcurrentuQueue per connection, wrapped in write-only-interface, being passed as a Actor

tobi commented on A minimal actor framework

Wed, 04 May 2011 09:47:27 GMT

The queue is unbounded.

Patrick Huizinga commented on A minimal actor framework

Wed, 04 May 2011 09:27:35 GMT

State shouldn't be public. It should only be editable from the activeTask thread.

Ayende Rahien commented on A minimal actor framework

Wed, 04 May 2011 09:22:31 GMT

Tobi, Great that you spotted that! What else? Look for design issues.

Idsa commented on A minimal actor framework

Wed, 04 May 2011 09:18:26 GMT

lock (this) is not a good idea

tobi commented on A minimal actor framework

Wed, 04 May 2011 09:15:49 GMT

It has a bug. The task could be just before "activeTask = null;" and the Act method could still exit due to "if (activeTask != null)" being true. A new task would not be started.