Discussion on Actor Usage

[yanzhanglin]

If I have a device(as a actor),This device communicates through serial port(as a actor)

now have two options:

1. Start the device operator first, and then start the serial port as a nested actor. When controlling the device, send commands to the device , and the device sends commands to the serial port actor, and then return data.

2. Start the serial port actor directly, then send commands directly to the serial port actorand return data.

Which option is better

[justACS]

3.  Wrap serial port communications in a class, and pass the class into the Device Operator.

You only need the port to be its own actor if it serves data to multiple entities, or if you have long response times from the instrument and need to keep the actor responsive.  (And the latter case may be better served with a helper loop.)

[yanzhanglin]

Do you mean to treat serial ports as regular classes？

[TurboTobi]

Hi yanzhanglin!

You can wrap the hole serial communication in a class and just use this class in your device operator. The advantage would be, that you can use this class in every actor to communicate through serial communication, but you will get in trouble if several devices using the same serial port. I wouldn't recommend it.

It is very likely that you will have a serial port, which will be used from several actors. 

Assume you have several devices communicating through the same serial port.

I would recommend you to do it with option 1.

This means you can reuse and extend your serial actor as you wish in the future.

It's the device, which uses the storm serial port not the serial port, which uses the device.

I hope it helps. 😄

[justACS]

---

@yanzhanglin wrote:

Do you mean to treat serial ports as regular classes？

---

Correct.  Serial communication is inherently command/response (as opposed to actors, which use announcements), and you haven’t mentioned anything to suggest that the communication needs its own thread.

The device operator, on the other hand, is the thing doing interesting work, and thus likely needs its own thread.

[justACS]

---

@TurboTobi wrote:

It is very likely that you will have a serial port, which will be used from several actors. 

Assume you have several devices communicating through the same serial port.

---

 That would have to be something like RS-485 and multiple addresses.  An actor might make sense in that case.  Even then, it might make more sense to initialize a port class and pass it to the individual device operators prior to launching them, if the devices respond fast enough.

[AristosQueue]

I prefer to have consumer actors spawn producer actors for external communications. That way when data starts rolling in, there's someone there already to handle it. If you start the external communications actor first, it has to batch up the data until a handler actor becomes available. Sure, that's easy to do in the actor queue, but you're forever after in a backlog situation unless the consumer eventually catches up. Also, when the consumer finishes digesting the data from the serial port, it has to send it to somewhere, and passing it back up the actor tree through the serial actor just puts needless complexity in the serial actor. 

In short, I'd always have the device actor start the serial port actor. 

(I am assuming you have your own good reasons for the serial communication being its own actor. If not, the other comments in this thread apply!) 

[Taggart]

---

@justACS wrote:

---

@yanzhanglin wrote:

Do you mean to treat serial ports as regular classes？

---

Correct.  Serial communication is inherently command/response (as opposed to actors, which use announcements), and you haven’t mentioned anything to suggest that the communication needs its own thread.

The device operator, on the other hand, is the thing doing interesting work, and thus likely needs its own thread.

---

Exactly this. Only make things asynchronous if you have to. Most serial comms is synchronous.