[scala] Actors and scheduling

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[scala] Actors and scheduling

David MacIver
I've never really got around to figuring out Scala's actors. No
particular reason, just haven't had a need for them. Well, now I
finally do have a need for them and (of course) it's requires me to
dive straight into the hard bits. Doing thing the easy way is boring.
:-)

Specifically, I need to have an Actor which runs on a specific thread.
I have mechanisms for scheduling tasks on that thread (or can create
such). An example is the Swing EDT (it's not actually the one I care
about - I want to do this with QT Jambi - but the concept is the same,
and this is simpler), and the actor should play nicely with those -
e.g. recieving multiple messages should allow for other things to be
executed between message reads.

Now, I think "all" I need to do here is implement the IScheduler trait
with some appropriate methods for running things on this thread. I
think I can figure out how to do that (I have my doubts about how
certain aspects will work, but more questions on that later). The
problem is that what I *can't* seem to figure out is how to assign
schedulers on an actor specific basis. The only mechanism I can find
for providing one is a global variable on Scheduler.

Now, I could create a Scheduler which wraps two schedulers and
selectively dispatches to them, then do something like Scheduler.impl
= wrapper(Scheduler.impl). But that's horrible. Surely there must be a
better way?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [scala] Actors and scheduling

Philipp Haller-2
David MacIver wrote:
> Specifically, I need to have an Actor which runs on a specific thread.
> I have mechanisms for scheduling tasks on that thread (or can create
> such). An example is the Swing EDT (it's not actually the one I care
> about - I want to do this with QT Jambi - but the concept is the same,
> and this is simpler), and the actor should play nicely with those -
> e.g. recieving multiple messages should allow for other things to be
> executed between message reads.

OK, so this can surely be done (see below); just make sure to use
`react` to receive messages, so that the Jambi thread is released when
the actor waits for a message.

> Now, I think "all" I need to do here is implement the IScheduler trait
> with some appropriate methods for running things on this thread. I
> think I can figure out how to do that (I have my doubts about how
> certain aspects will work, but more questions on that later). The
> problem is that what I *can't* seem to figure out is how to assign
> schedulers on an actor specific basis. The only mechanism I can find
> for providing one is a global variable on Scheduler.

Indeed, currently there is no way to assign schedulers on an actor
specific basis.

> Now, I could create a Scheduler which wraps two schedulers and
> selectively dispatches to them, then do something like Scheduler.impl
> = wrapper(Scheduler.impl). But that's horrible. Surely there must be a
> better way?

Another way would be to subclass the `Actor` trait and override the
`scheduleActor` method so that it schedules its task to be run on your
specific thread. The overridden method should look exactly like the one
in `Actor` except that it replaces `Scheduler execute task` with your
own scheduling code. I think this would be cleaner (and also faster).
However there is one slightly ugly thing left to do: the `send` method
in `Actor` also has to be overridden since it contains an inlined
version of the `scheduleActor` method. Here, again you have to replace
the call to `Scheduler.execute` with your own code.

It would be good to flesh this out into a nice interface.

Cheers,
Philipp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [scala] Actors and scheduling

David MacIver
Hi Phillip,

Thanks for your response. By the way, your site seems to be not
working at the moment so I had trouble finding most of the information
on actors that's usually on it.

On Tue, May 13, 2008 at 8:43 AM, Philipp Haller <[hidden email]> wrote:

> David MacIver wrote:
>  > Specifically, I need to have an Actor which runs on a specific thread.
>  > I have mechanisms for scheduling tasks on that thread (or can create
>  > such). An example is the Swing EDT (it's not actually the one I care
>  > about - I want to do this with QT Jambi - but the concept is the same,
>  > and this is simpler), and the actor should play nicely with those -
>  > e.g. recieving multiple messages should allow for other things to be
>  > executed between message reads.
>
>  OK, so this can surely be done (see below); just make sure to use
>  `react` to receive messages, so that the Jambi thread is released when
>  the actor waits for a message.

Ok.

>  > Now, I think "all" I need to do here is implement the IScheduler trait
>  > with some appropriate methods for running things on this thread. I
>  > think I can figure out how to do that (I have my doubts about how
>  > certain aspects will work, but more questions on that later). The
>  > problem is that what I *can't* seem to figure out is how to assign
>  > schedulers on an actor specific basis. The only mechanism I can find
>  > for providing one is a global variable on Scheduler.
>
>  Indeed, currently there is no way to assign schedulers on an actor
>  specific basis.

Are there plans to fix that? It seems like something one really should
be able to do (see e.g. this use case. I'm quite sure that scala-swing
and future GUI projects in Scala would benefit from it), and config by
global variable is a bit awful. :-)

>  > Now, I could create a Scheduler which wraps two schedulers and
>  > selectively dispatches to them, then do something like Scheduler.impl
>  > = wrapper(Scheduler.impl). But that's horrible. Surely there must be a
>  > better way?
>
>  Another way would be to subclass the `Actor` trait and override the
>  `scheduleActor` method so that it schedules its task to be run on your
>  specific thread. The overridden method should look exactly like the one
>  in `Actor` except that it replaces `Scheduler execute task` with your
>  own scheduling code. I think this would be cleaner (and also faster).
>
>  However there is one slightly ugly thing left to do: the `send` method
>  in `Actor` also has to be overridden since it contains an inlined
>  version of the `scheduleActor` method. Here, again you have to replace
>  the call to `Scheduler.execute` with your own code.
>
>  It would be good to flesh this out into a nice interface.

Yes, that seems a lot better. But it's more than just send. There are
various hardcoded references to "Scheduler" in Actor, not just the
scheduleActor method. In particular it seems to appear in:

scheduleActor
start
send
tick

And tick is private, so it can't be overridden. :-( Which means that
I'd also have to replace anything which calls tick as well, including

receive (it looks like I shouldn't use this anyway?)
receiveWithin (ditto)
react
reactWithin

The right way to fix this is probably at the actor implementation
level, providing Actor with a def scheduler which points to some
global scheduler by default and can be overridden to customise
scheduling behaviour. I note that the Scheduler object doesn't seem to
extend IScheduler even though they have largely the same interface (it
offers a few more methods that I think are mostly to do with its
delegation). Would it be possible to change that?

As it currently stands it's starting to look like the amount of work
needed to make actors do what I need to do is noticeably greater than
the amount of work it would take me to just define my own custom
message passing interface that does what I need out of the box, as my
needs are very simple (I basically don't even need the behaviour in
response to a message to depend on previously seen messages).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [scala] Actors and scheduling

Meredith Gregory
Philipp,

If one allows scheduling to be overridden, what are the actor fairness guarantees? Is there a simple, straightforward statement of properties a scheduling implementation needs to respect (analogous to something like the monad laws that every instance of monad needs to guarantee in Haskell)?

Hewitt-Agha actors demand -- at least -- no infinite prefixes in a mailbox. Is there a similar, simple statement of fairness for Scala actors? i'm motivated to ask this because i'm contemplating a behavioral types system for Scala actors; but, if scheduling semantics are not sufficiently constrained the compile time guarantees of the type system will be meaningless.

Best wishes,

--greg

On Tue, May 13, 2008 at 1:14 AM, David MacIver <[hidden email]> wrote:
Hi Phillip,

Thanks for your response. By the way, your site seems to be not
working at the moment so I had trouble finding most of the information
on actors that's usually on it.

On Tue, May 13, 2008 at 8:43 AM, Philipp Haller <[hidden email]> wrote:
> David MacIver wrote:
>  > Specifically, I need to have an Actor which runs on a specific thread.
>  > I have mechanisms for scheduling tasks on that thread (or can create
>  > such). An example is the Swing EDT (it's not actually the one I care
>  > about - I want to do this with QT Jambi - but the concept is the same,
>  > and this is simpler), and the actor should play nicely with those -
>  > e.g. recieving multiple messages should allow for other things to be
>  > executed between message reads.
>
>  OK, so this can surely be done (see below); just make sure to use
>  `react` to receive messages, so that the Jambi thread is released when
>  the actor waits for a message.

Ok.

>  > Now, I think "all" I need to do here is implement the IScheduler trait
>  > with some appropriate methods for running things on this thread. I
>  > think I can figure out how to do that (I have my doubts about how
>  > certain aspects will work, but more questions on that later). The
>  > problem is that what I *can't* seem to figure out is how to assign
>  > schedulers on an actor specific basis. The only mechanism I can find
>  > for providing one is a global variable on Scheduler.
>
>  Indeed, currently there is no way to assign schedulers on an actor
>  specific basis.

Are there plans to fix that? It seems like something one really should
be able to do (see e.g. this use case. I'm quite sure that scala-swing
and future GUI projects in Scala would benefit from it), and config by
global variable is a bit awful. :-)

>  > Now, I could create a Scheduler which wraps two schedulers and
>  > selectively dispatches to them, then do something like Scheduler.impl
>  > = wrapper(Scheduler.impl). But that's horrible. Surely there must be a
>  > better way?
>
>  Another way would be to subclass the `Actor` trait and override the
>  `scheduleActor` method so that it schedules its task to be run on your
>  specific thread. The overridden method should look exactly like the one
>  in `Actor` except that it replaces `Scheduler execute task` with your
>  own scheduling code. I think this would be cleaner (and also faster).
>
>  However there is one slightly ugly thing left to do: the `send` method
>  in `Actor` also has to be overridden since it contains an inlined
>  version of the `scheduleActor` method. Here, again you have to replace
>  the call to `Scheduler.execute` with your own code.
>
>  It would be good to flesh this out into a nice interface.

Yes, that seems a lot better. But it's more than just send. There are
various hardcoded references to "Scheduler" in Actor, not just the
scheduleActor method. In particular it seems to appear in:

scheduleActor
start
send
tick

And tick is private, so it can't be overridden. :-( Which means that
I'd also have to replace anything which calls tick as well, including

receive (it looks like I shouldn't use this anyway?)
receiveWithin (ditto)
react
reactWithin

The right way to fix this is probably at the actor implementation
level, providing Actor with a def scheduler which points to some
global scheduler by default and can be overridden to customise
scheduling behaviour. I note that the Scheduler object doesn't seem to
extend IScheduler even though they have largely the same interface (it
offers a few more methods that I think are mostly to do with its
delegation). Would it be possible to change that?

As it currently stands it's starting to look like the amount of work
needed to make actors do what I need to do is noticeably greater than
the amount of work it would take me to just define my own custom
message passing interface that does what I need out of the box, as my
needs are very simple (I basically don't even need the behaviour in
response to a message to depend on previously seen messages).



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com
Loading...