Hi all,
I have a simple question (but I didn't find a good answer looking at the mailing list): which is the _best_ way to communicate with a serial port using an orocos component? (in order to don't break realtime things while the component is reading from the port..)
Enea
Best way to communicate with serial port
I'm curious to this answer as well. We use some USB components which have the same issue.
Tim
-----Original Message-----
From: orocos-users-bounces [..] ... [mailto:orocos-users-bounces [..] ...] On Behalf Of enea [dot] scioni [..] ...
Sent: dinsdag 5 april 2011 15:23
To: orocos-users [..] ...
Subject: [Orocos-users] Best way to communicate with serial port
Hi all,
I have a simple question (but I didn't find a good answer looking at the mailing list): which is the _best_ way to communicate with a serial port using an orocos component?
(in order to don't break realtime things while the component is reading from the port..)
Enea
Best way to communicate with serial port
On Mon, 11 Apr 2011, Clephas, T.T.G. wrote:
> I'm curious to this answer as well. We use some USB components which have
> the same issue.
Foresee a component that can do the "active waiting", provide its
outputs via a Port, and choose a "port reaction" policy that fits to your
system needs.
> Tim
Herman
> -----Original Message-----
> From: orocos-users-bounces [..] ... [mailto:orocos-users-bounces [..] ...] On Behalf Of enea [dot] scioni [..] ...
> Sent: dinsdag 5 april 2011 15:23
> To: orocos-users [..] ...
> Subject: [Orocos-users] Best way to communicate with serial port
>
> Hi all,
>
> I have a simple question (but I didn't find a good answer looking at the mailing list): which is the _best_ way to communicate with a serial port using an orocos component?
> (in order to don't break realtime things while the component is reading from the port..)
>
> Enea
Best way to communicate with
I make a component that require a non periodic activity.
In the updateHook, i block on read (a poll to be exact).
When the read finish, i process data and i call trigger.
To avoid the poll, i never tried the FileDescriptorActivity, but it should be possible.
Best way to communicate with
On 04/06/2011 04:07 PM, paul [dot] chavent [..] ... wrote:
> I make a component that require a non periodic activity.
>
> In the updateHook, i block on read (a poll to be exact).
If you block on a poll, then FileDescriptorActivity is *exactly* what
you need.
It basically does a select() (with a configurable timeout), but provides
all the activity interface needed to have stop() or port triggers work
fine (i.e. it implements breakLoop() and trigger())
Sylvain
Best way to communicate with
On Wed, 6 Apr 2011, paul [dot] chavent [..] ... wrote:
> I make a component that require a non periodic activity.
> In the updateHook, i block on read (a poll to be exact).
Not the smartest policy, I guess...
> When the read finish, i process data and i call trigger.
> To avoid the poll, i never tried the FileDescriptorActivity, but it
> should be possible.
Or you add another activity that does the waiting for you, and that
provides its results via a Port that your periodic activity can read
(without blocking).
Hemran
Best way to communicate with
On Apr 6, 2011, at 10:11 , Herman Bruyninckx wrote:
> On Wed, 6 Apr 2011, paul [dot] chavent [..] ... wrote:
>
>> I make a component that require a non periodic activity.
>> In the updateHook, i block on read (a poll to be exact).
>
> Not the smartest policy, I guess...
The non-periodic, the block, the read, the poll ... which isn't smart?
>> When the read finish, i process data and i call trigger.
>> To avoid the poll, i never tried the FileDescriptorActivity, but it
>> should be possible.
>
> Or you add another activity that does the waiting for you, and that
> provides its results via a Port that your periodic activity can read
> (without blocking).
We _regularly_ have to structure components like Paul asked about, primarily as we use state machines to manage the behaviour of the components. Blocking or otherwise. And separating the activity isn't a solution in our situations, so I'm sure others face similar problems.
We don't use the FileDescriptorActivity, but use a standard periodic Activity. These are fairly tolerant to blocking calls (though see a recent post on the ML if you are using v1 RTT). There can be issues stopping such tasks - they block for a couple of seconds before deciding to stop forcibly (at least in v1 RTT). But they allow you to manage behaviour in a blocking component, which is incredibly useful ...
Others should be able to comment on whether FileDescriptorActivity better suits your goals.
Sometimes you have to compromise ...
S
Best way to communicate with
On Wed, 6 Apr 2011, S Roderick wrote:
> On Apr 6, 2011, at 10:11 , Herman Bruyninckx wrote:
>
>> On Wed, 6 Apr 2011, paul [dot] chavent [..] ... wrote:
>>
>>> I make a component that require a non periodic activity.
>>> In the updateHook, i block on read (a poll to be exact).
>>
>> Not the smartest policy, I guess...
>
> The non-periodic, the block, the read, the poll ... which isn't smart?
The _combination_ of all these :-)
>>> When the read finish, i process data and i call trigger.
>>> To avoid the poll, i never tried the FileDescriptorActivity, but it
>>> should be possible.
>>
>> Or you add another activity that does the waiting for you, and that
>> provides its results via a Port that your periodic activity can read
>> (without blocking).
>
> We _regularly_ have to structure components like Paul asked about,
> primarily as we use state machines to manage the behaviour of the
> components. Blocking or otherwise. And separating the activity isn't a
> solution in our situations, so I'm sure others face similar problems.
I don't understand exactly why you are "forced" to use this architecture...
> We don't use the FileDescriptorActivity, but use a standard periodic
> Activity. These are fairly tolerant to blocking calls (though see a
> recent post on the ML if you are using v1 RTT). There can be issues
> stopping such tasks - they block for a couple of seconds before deciding
> to stop forcibly (at least in v1 RTT). But they allow you to manage
> behaviour in a blocking component, which is incredibly useful ...
Why exactly is it "incredibly useful"...?
> Others should be able to comment on whether FileDescriptorActivity better
> suits your goals.
I do not like the "FileDescriptorActivity" _at all_: it is an example of a
bad practice, naming something after _one specific_ goal ("policy"),
instead of naming it after the generally useful _mechanism_ (i.c.,
subcontracting an Activity to do the blocking waiting for you).
> Sometimes you have to compromise ...
> S
Herman
Re: Best way to communicate with
> The non-periodic, the block, the read, the poll ... which isn't smart?
The _combination_ of all these :-)
Best way to communicate with
On 04/06/2011 04:25 PM, Herman Bruyninckx wrote:
> On Wed, 6 Apr 2011, S Roderick wrote:
>
>> On Apr 6, 2011, at 10:11 , Herman Bruyninckx wrote:
>>
>>> On Wed, 6 Apr 2011, paul [dot] chavent [..] ... wrote:
>>>
>>>> I make a component that require a non periodic activity.
>>>> In the updateHook, i block on read (a poll to be exact).
>>>
>>> Not the smartest policy, I guess...
>>
>> The non-periodic, the block, the read, the poll ... which isn't smart?
>
> The _combination_ of all these :-)
>
>>>> When the read finish, i process data and i call trigger.
>>>> To avoid the poll, i never tried the FileDescriptorActivity, but it
>>>> should be possible.
>>>
>>> Or you add another activity that does the waiting for you, and that
>>> provides its results via a Port that your periodic activity can read
>>> (without blocking).
>>
>> We _regularly_ have to structure components like Paul asked about,
>> primarily as we use state machines to manage the behaviour of the
>> components. Blocking or otherwise. And separating the activity isn't a
>> solution in our situations, so I'm sure others face similar problems.
>
> I don't understand exactly why you are "forced" to use this architecture...
>
>> We don't use the FileDescriptorActivity, but use a standard periodic
>> Activity. These are fairly tolerant to blocking calls (though see a
>> recent post on the ML if you are using v1 RTT). There can be issues
>> stopping such tasks - they block for a couple of seconds before deciding
>> to stop forcibly (at least in v1 RTT). But they allow you to manage
>> behaviour in a blocking component, which is incredibly useful ...
>
> Why exactly is it "incredibly useful"...?
>
>> Others should be able to comment on whether FileDescriptorActivity better
>> suits your goals.
>
> I do not like the "FileDescriptorActivity" _at all_: it is an example of a
> bad practice, naming something after _one specific_ goal ("policy"),
> instead of naming it after the generally useful _mechanism_ (i.c.,
> subcontracting an Activity to do the blocking waiting for you).
???
I don't get that *at all*
Activities are the triggering / threading mechanism behind the
components. The FileDescriptorActivity, instead of waiting on trigger()
(Activity) or timer (Activity with period, which *is* a
PeriodicActivity), waits for data on a file descriptor (hence the name).
What's your problem with that ?
The "generally useful mechanism" *is Activity itself*. Every implemented
activity is then *a* policy that implements *that generally useful
mechanism*. Adding one more layer of genericity makes absolutely no
sense in my opinion.
Best way to communicate with
On Wed, 6 Apr 2011, Sylvain Joyeux wrote:
> On 04/06/2011 04:25 PM, Herman Bruyninckx wrote:
>> On Wed, 6 Apr 2011, S Roderick wrote:
>>
>>> On Apr 6, 2011, at 10:11 , Herman Bruyninckx wrote:
>>>
>>>> On Wed, 6 Apr 2011, paul [dot] chavent [..] ... wrote:
>>>>
>>>>> I make a component that require a non periodic activity.
>>>>> In the updateHook, i block on read (a poll to be exact).
>>>>
>>>> Not the smartest policy, I guess...
>>>
>>> The non-periodic, the block, the read, the poll ... which isn't smart?
>>
>> The _combination_ of all these :-)
>>
>>>>> When the read finish, i process data and i call trigger.
>>>>> To avoid the poll, i never tried the FileDescriptorActivity, but it
>>>>> should be possible.
>>>>
>>>> Or you add another activity that does the waiting for you, and that
>>>> provides its results via a Port that your periodic activity can read
>>>> (without blocking).
>>>
>>> We _regularly_ have to structure components like Paul asked about,
>>> primarily as we use state machines to manage the behaviour of the
>>> components. Blocking or otherwise. And separating the activity isn't a
>>> solution in our situations, so I'm sure others face similar problems.
>>
>> I don't understand exactly why you are "forced" to use this architecture...
>>
>>> We don't use the FileDescriptorActivity, but use a standard periodic
>>> Activity. These are fairly tolerant to blocking calls (though see a
>>> recent post on the ML if you are using v1 RTT). There can be issues
>>> stopping such tasks - they block for a couple of seconds before deciding
>>> to stop forcibly (at least in v1 RTT). But they allow you to manage
>>> behaviour in a blocking component, which is incredibly useful ...
>>
>> Why exactly is it "incredibly useful"...?
>>
>>> Others should be able to comment on whether FileDescriptorActivity better
>>> suits your goals.
>>
>> I do not like the "FileDescriptorActivity" _at all_: it is an example of a
>> bad practice, naming something after _one specific_ goal ("policy"),
>> instead of naming it after the generally useful _mechanism_ (i.c.,
>> subcontracting an Activity to do the blocking waiting for you).
> ???
>
> I don't get that *at all*
>
> Activities are the triggering / threading mechanism behind the
> components. The FileDescriptorActivity, instead of waiting on trigger()
> (Activity) or timer (Activity with period, which *is* a
> PeriodicActivity), waits for data on a file descriptor (hence the name).
yes, and that's what I am complaining about: the _mechanism_ of waiting for
a blocking operation is what counts, while waiting for "data on a file
descriptor" is just one of the many _policies_ that one can build on top of
the generic mechanism.
> What's your problem with that ?
Giving wrong names is a bad design decision.
> The "generally useful mechanism" *is Activity itself*. Every implemented
> activity is then *a* policy that implements *that generally useful
> mechanism*. Adding one more layer of genericity makes absolutely no
> sense in my opinion.
I absolutely agree. That's why I said previously that I am not happy that
"FileDescriptorActivity" ever made it into RTT...
> Sylvain Joyeux (Dr.Ing.)
Herman
Best way to communicate with serial port
2011/4/5 enea [dot] scioni [..] ... <enea [dot] scioni [..] ...>
> Hi all,
>
> I have a simple question (but I didn't find a good answer looking at the
> mailing list): which is the _best_ way to communicate with a serial port
> using an orocos component?
> (in order to don't break realtime things while the component is reading
> from the port..)
>
That would be the FileDescriptorActivity:
http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/classRTT_1_...
Steven
> Enea
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Best way to communicate with
On 04/06/2011 10:21 PM, Herman Bruyninckx wrote:
> On Wed, 6 Apr 2011, Sylvain Joyeux wrote:
>
>> On 04/06/2011 04:25 PM, Herman Bruyninckx wrote:
>>> On Wed, 6 Apr 2011, S Roderick wrote:
>>>
>>>> On Apr 6, 2011, at 10:11 , Herman Bruyninckx wrote:
>>>>
>>>>> On Wed, 6 Apr 2011, paul [dot] chavent [..] ... wrote:
>>>>>
>>>>>> I make a component that require a non periodic activity.
>>>>>> In the updateHook, i block on read (a poll to be exact).
>>>>>
>>>>> Not the smartest policy, I guess...
>>>>
>>>> The non-periodic, the block, the read, the poll ... which isn't smart?
>>>
>>> The _combination_ of all these :-)
>>>
>>>>>> When the read finish, i process data and i call trigger.
>>>>>> To avoid the poll, i never tried the FileDescriptorActivity, but it
>>>>>> should be possible.
>>>>>
>>>>> Or you add another activity that does the waiting for you, and that
>>>>> provides its results via a Port that your periodic activity can read
>>>>> (without blocking).
>>>>
>>>> We _regularly_ have to structure components like Paul asked about,
>>>> primarily as we use state machines to manage the behaviour of the
>>>> components. Blocking or otherwise. And separating the activity isn't a
>>>> solution in our situations, so I'm sure others face similar problems.
>>>
>>> I don't understand exactly why you are "forced" to use this
>>> architecture...
>>>
>>>> We don't use the FileDescriptorActivity, but use a standard periodic
>>>> Activity. These are fairly tolerant to blocking calls (though see a
>>>> recent post on the ML if you are using v1 RTT). There can be issues
>>>> stopping such tasks - they block for a couple of seconds before
>>>> deciding
>>>> to stop forcibly (at least in v1 RTT). But they allow you to manage
>>>> behaviour in a blocking component, which is incredibly useful ...
>>>
>>> Why exactly is it "incredibly useful"...?
>>>
>>>> Others should be able to comment on whether FileDescriptorActivity
>>>> better
>>>> suits your goals.
>>>
>>> I do not like the "FileDescriptorActivity" _at all_: it is an example
>>> of a
>>> bad practice, naming something after _one specific_ goal ("policy"),
>>> instead of naming it after the generally useful _mechanism_ (i.c.,
>>> subcontracting an Activity to do the blocking waiting for you).
>> ???
>>
>> I don't get that *at all*
>>
>> Activities are the triggering / threading mechanism behind the
>> components. The FileDescriptorActivity, instead of waiting on trigger()
>> (Activity) or timer (Activity with period, which *is* a
>> PeriodicActivity), waits for data on a file descriptor (hence the name).
>
> yes, and that's what I am complaining about: the _mechanism_ of waiting for
> a blocking operation is what counts, while waiting for "data on a file
> descriptor" is just one of the many _policies_ that one can build on top of
> the generic mechanism.
This is implementation details, not general design decisions. You think
that one should implement a generic "wait for blocking things". Well, it
does exist and it is called Activity, which provides the interface to
implement whatever policy you want on top of it.
Then FileDescriptorActivity is such a policy, which -- as its name
states -- is a specific policy that waits on having data on IO.
In other words, you're complaining about a bad design in RTT that
*already exists* !
Sylvain
Best way to communicate with
On Thu, 7 Apr 2011, Sylvain Joyeux wrote:
> On 04/06/2011 10:21 PM, Herman Bruyninckx wrote:
>> On Wed, 6 Apr 2011, Sylvain Joyeux wrote:
>>
>>> On 04/06/2011 04:25 PM, Herman Bruyninckx wrote:
>>>> On Wed, 6 Apr 2011, S Roderick wrote:
>>>>
>>>>> On Apr 6, 2011, at 10:11 , Herman Bruyninckx wrote:
>>>>>
>>>>>> On Wed, 6 Apr 2011, paul [dot] chavent [..] ... wrote:
>>>>>>
>>>>>>> I make a component that require a non periodic activity.
>>>>>>> In the updateHook, i block on read (a poll to be exact).
>>>>>>
>>>>>> Not the smartest policy, I guess...
>>>>>
>>>>> The non-periodic, the block, the read, the poll ... which isn't smart?
>>>>
>>>> The _combination_ of all these :-)
>>>>
>>>>>>> When the read finish, i process data and i call trigger.
>>>>>>> To avoid the poll, i never tried the FileDescriptorActivity, but it
>>>>>>> should be possible.
>>>>>>
>>>>>> Or you add another activity that does the waiting for you, and that
>>>>>> provides its results via a Port that your periodic activity can read
>>>>>> (without blocking).
>>>>>
>>>>> We _regularly_ have to structure components like Paul asked about,
>>>>> primarily as we use state machines to manage the behaviour of the
>>>>> components. Blocking or otherwise. And separating the activity isn't a
>>>>> solution in our situations, so I'm sure others face similar problems.
>>>>
>>>> I don't understand exactly why you are "forced" to use this
>>>> architecture...
>>>>
>>>>> We don't use the FileDescriptorActivity, but use a standard periodic
>>>>> Activity. These are fairly tolerant to blocking calls (though see a
>>>>> recent post on the ML if you are using v1 RTT). There can be issues
>>>>> stopping such tasks - they block for a couple of seconds before
>>>>> deciding
>>>>> to stop forcibly (at least in v1 RTT). But they allow you to manage
>>>>> behaviour in a blocking component, which is incredibly useful ...
>>>>
>>>> Why exactly is it "incredibly useful"...?
>>>>
>>>>> Others should be able to comment on whether FileDescriptorActivity
>>>>> better
>>>>> suits your goals.
>>>>
>>>> I do not like the "FileDescriptorActivity" _at all_: it is an example
>>>> of a
>>>> bad practice, naming something after _one specific_ goal ("policy"),
>>>> instead of naming it after the generally useful _mechanism_ (i.c.,
>>>> subcontracting an Activity to do the blocking waiting for you).
>>> ???
>>>
>>> I don't get that *at all*
>>>
>>> Activities are the triggering / threading mechanism behind the
>>> components. The FileDescriptorActivity, instead of waiting on trigger()
>>> (Activity) or timer (Activity with period, which *is* a
>>> PeriodicActivity), waits for data on a file descriptor (hence the name).
>>
>> yes, and that's what I am complaining about: the _mechanism_ of waiting for
>> a blocking operation is what counts, while waiting for "data on a file
>> descriptor" is just one of the many _policies_ that one can build on top of
>> the generic mechanism.
> This is implementation details, not general design decisions. You think
> that one should implement a generic "wait for blocking things". Well, it
> does exist and it is called Activity, which provides the interface to
> implement whatever policy you want on top of it.
>
> Then FileDescriptorActivity is such a policy, which -- as its name
> states -- is a specific policy that waits on having data on IO.
>
> In other words, you're complaining about a bad design in RTT that
> *already exists* !
You are absolutely right. And I have said so much already twice :-)
And if you want to open a Pandora box: I still have a long list of things I
personally think are not done correctly in RTT for the time being. :-)
> Sylvain
Herman
Best way to communicate with
On 04/07/2011 11:41 AM, Herman Bruyninckx wrote:
>> In other words, you're complaining about a bad design in RTT that
>> *already exists* !
>
> You are absolutely right. And I have said so much already twice :-)
Ah ... I wrote the inverse of what I actually wanted to say ...
You complain that FileDescriptorActivity should not be because you want
a "generic activity for blocking things". This generic handler already
exists: it is Activity itself. What's left to write are the specific
policies, and FileDescriptorActivity is one of them.
Best way to communicate with
On Thu, 7 Apr 2011, Sylvain Joyeux wrote:
> On 04/07/2011 11:41 AM, Herman Bruyninckx wrote:
>>> In other words, you're complaining about a bad design in RTT that
>>> *already exists* !
>>
>> You are absolutely right. And I have said so much already twice :-)
> Ah ... I wrote the inverse of what I actually wanted to say ...
>
> You complain that FileDescriptorActivity should not be because you want
> a "generic activity for blocking things". This generic handler already
> exists: it is Activity itself. What's left to write are the specific
> policies, and FileDescriptorActivity is one of them.
The policy should be part of "Configuration", and not be promoted to a
full-fledged primitive in itself. The configuration would contain data,
such as: on which event is to be waited, with what time-out, etc.
> Sylvain Joyeux (Dr.Ing.)
Herman
Best way to communicate with
On 04/08/2011 12:01 AM, Herman Bruyninckx wrote:
> The policy should be part of "Configuration", and not be promoted to a
> full-fledged primitive in itself. The configuration would contain data,
> such as: on which event is to be waited, with what time-out, etc.
And it's already there
if (policy == 'wait_on_fd')
deploy_task_with(FileDescriptorActivity,
timeout=<configuration_timeout>, error_policy=<define_error_policy>)
My point, really.
Best way to communicate with
On 04/08/2011 11:49 AM, Sylvain Joyeux wrote:
> On 04/08/2011 12:01 AM, Herman Bruyninckx wrote:
>> The policy should be part of "Configuration", and not be promoted to a
>> full-fledged primitive in itself. The configuration would contain data,
>> such as: on which event is to be waited, with what time-out, etc.
>
> And it's already there
>
> if (policy == 'wait_on_fd')
> deploy_task_with(FileDescriptorActivity,
> timeout=<configuration_timeout>, error_policy=<define_error_policy>)
>
> My point, really.
To make it clearer:
Saying that FileDescriptorActivity is baaaaad because it should be part
of the configuration interface is wrong *if* you see picking the right
activity as part of the configuration interface. Which I do, since it
involves choosing the threading model, the threading priority and so on
and so forth (i.e. part of "deploying", and therefore part of
"configuration"). I don't see the point of adding a new class that would
duplicate what Activity and its subclasses do already just so that you
get a setPolicy(FD_ACTIVITY) method instead of "new FileDescriptorActivity".
I.e. this a matter of taste, not general design.
Sylvain
Best way to communicate with
On Apr 7, 2011, at 05:41 , Herman Bruyninckx wrote:
> On Thu, 7 Apr 2011, Sylvain Joyeux wrote:
>
>> On 04/06/2011 10:21 PM, Herman Bruyninckx wrote:
>>> On Wed, 6 Apr 2011, Sylvain Joyeux wrote:
>>>
>>>> On 04/06/2011 04:25 PM, Herman Bruyninckx wrote:
>>>>> On Wed, 6 Apr 2011, S Roderick wrote:
>>>>>
>>>>>> On Apr 6, 2011, at 10:11 , Herman Bruyninckx wrote:
>>>>>>
>>>>>>> On Wed, 6 Apr 2011, paul [dot] chavent [..] ... wrote:
>>>>>>>
>>>>>>>> I make a component that require a non periodic activity.
>>>>>>>> In the updateHook, i block on read (a poll to be exact).
>>>>>>>
>>>>>>> Not the smartest policy, I guess...
>>>>>>
>>>>>> The non-periodic, the block, the read, the poll ... which isn't smart?
>>>>>
>>>>> The _combination_ of all these :-)
>>>>>
>>>>>>>> When the read finish, i process data and i call trigger.
>>>>>>>> To avoid the poll, i never tried the FileDescriptorActivity, but it
>>>>>>>> should be possible.
>>>>>>>
>>>>>>> Or you add another activity that does the waiting for you, and that
>>>>>>> provides its results via a Port that your periodic activity can read
>>>>>>> (without blocking).
>>>>>>
>>>>>> We _regularly_ have to structure components like Paul asked about,
>>>>>> primarily as we use state machines to manage the behaviour of the
>>>>>> components. Blocking or otherwise. And separating the activity isn't a
>>>>>> solution in our situations, so I'm sure others face similar problems.
>>>>>
>>>>> I don't understand exactly why you are "forced" to use this
>>>>> architecture...
>>>>>
>>>>>> We don't use the FileDescriptorActivity, but use a standard periodic
>>>>>> Activity. These are fairly tolerant to blocking calls (though see a
>>>>>> recent post on the ML if you are using v1 RTT). There can be issues
>>>>>> stopping such tasks - they block for a couple of seconds before
>>>>>> deciding
>>>>>> to stop forcibly (at least in v1 RTT). But they allow you to manage
>>>>>> behaviour in a blocking component, which is incredibly useful ...
>>>>>
>>>>> Why exactly is it "incredibly useful"...?
>>>>>
>>>>>> Others should be able to comment on whether FileDescriptorActivity
>>>>>> better
>>>>>> suits your goals.
>>>>>
>>>>> I do not like the "FileDescriptorActivity" _at all_: it is an example
>>>>> of a
>>>>> bad practice, naming something after _one specific_ goal ("policy"),
>>>>> instead of naming it after the generally useful _mechanism_ (i.c.,
>>>>> subcontracting an Activity to do the blocking waiting for you).
>>>> ???
>>>>
>>>> I don't get that *at all*
>>>>
>>>> Activities are the triggering / threading mechanism behind the
>>>> components. The FileDescriptorActivity, instead of waiting on trigger()
>>>> (Activity) or timer (Activity with period, which *is* a
>>>> PeriodicActivity), waits for data on a file descriptor (hence the name).
>>>
>>> yes, and that's what I am complaining about: the _mechanism_ of waiting for
>>> a blocking operation is what counts, while waiting for "data on a file
>>> descriptor" is just one of the many _policies_ that one can build on top of
>>> the generic mechanism.
>> This is implementation details, not general design decisions. You think
>> that one should implement a generic "wait for blocking things". Well, it
>> does exist and it is called Activity, which provides the interface to
>> implement whatever policy you want on top of it.
>>
>> Then FileDescriptorActivity is such a policy, which -- as its name
>> states -- is a specific policy that waits on having data on IO.
>>
>> In other words, you're complaining about a bad design in RTT that
>> *already exists* !
>
> You are absolutely right. And I have said so much already twice :-)
>
> And if you want to open a Pandora box: I still have a long list of things I
> personally think are not done correctly in RTT for the time being. :-)
Well, it's an open source project. Go fix them then ... I'm sure we'd all welcome the contributions.
S
Best way to communicate with
On Thu, 7 Apr 2011, S Roderick wrote:
> On Apr 7, 2011, at 05:41 , Herman Bruyninckx wrote:
>
>> On Thu, 7 Apr 2011, Sylvain Joyeux wrote:
>>
>>> On 04/06/2011 10:21 PM, Herman Bruyninckx wrote:
>>>> On Wed, 6 Apr 2011, Sylvain Joyeux wrote:
>>>>
>>>>> On 04/06/2011 04:25 PM, Herman Bruyninckx wrote:
>>>>>> On Wed, 6 Apr 2011, S Roderick wrote:
>>>>>>
>>>>>>> On Apr 6, 2011, at 10:11 , Herman Bruyninckx wrote:
>>>>>>>
>>>>>>>> On Wed, 6 Apr 2011, paul [dot] chavent [..] ... wrote:
>>>>>>>>
>>>>>>>>> I make a component that require a non periodic activity.
>>>>>>>>> In the updateHook, i block on read (a poll to be exact).
>>>>>>>>
>>>>>>>> Not the smartest policy, I guess...
>>>>>>>
>>>>>>> The non-periodic, the block, the read, the poll ... which isn't smart?
>>>>>>
>>>>>> The _combination_ of all these :-)
>>>>>>
>>>>>>>>> When the read finish, i process data and i call trigger.
>>>>>>>>> To avoid the poll, i never tried the FileDescriptorActivity, but it
>>>>>>>>> should be possible.
>>>>>>>>
>>>>>>>> Or you add another activity that does the waiting for you, and that
>>>>>>>> provides its results via a Port that your periodic activity can read
>>>>>>>> (without blocking).
>>>>>>>
>>>>>>> We _regularly_ have to structure components like Paul asked about,
>>>>>>> primarily as we use state machines to manage the behaviour of the
>>>>>>> components. Blocking or otherwise. And separating the activity isn't a
>>>>>>> solution in our situations, so I'm sure others face similar problems.
>>>>>>
>>>>>> I don't understand exactly why you are "forced" to use this
>>>>>> architecture...
>>>>>>
>>>>>>> We don't use the FileDescriptorActivity, but use a standard periodic
>>>>>>> Activity. These are fairly tolerant to blocking calls (though see a
>>>>>>> recent post on the ML if you are using v1 RTT). There can be issues
>>>>>>> stopping such tasks - they block for a couple of seconds before
>>>>>>> deciding
>>>>>>> to stop forcibly (at least in v1 RTT). But they allow you to manage
>>>>>>> behaviour in a blocking component, which is incredibly useful ...
>>>>>>
>>>>>> Why exactly is it "incredibly useful"...?
>>>>>>
>>>>>>> Others should be able to comment on whether FileDescriptorActivity
>>>>>>> better
>>>>>>> suits your goals.
>>>>>>
>>>>>> I do not like the "FileDescriptorActivity" _at all_: it is an example
>>>>>> of a
>>>>>> bad practice, naming something after _one specific_ goal ("policy"),
>>>>>> instead of naming it after the generally useful _mechanism_ (i.c.,
>>>>>> subcontracting an Activity to do the blocking waiting for you).
>>>>> ???
>>>>>
>>>>> I don't get that *at all*
>>>>>
>>>>> Activities are the triggering / threading mechanism behind the
>>>>> components. The FileDescriptorActivity, instead of waiting on trigger()
>>>>> (Activity) or timer (Activity with period, which *is* a
>>>>> PeriodicActivity), waits for data on a file descriptor (hence the name).
>>>>
>>>> yes, and that's what I am complaining about: the _mechanism_ of waiting for
>>>> a blocking operation is what counts, while waiting for "data on a file
>>>> descriptor" is just one of the many _policies_ that one can build on top of
>>>> the generic mechanism.
>>> This is implementation details, not general design decisions. You think
>>> that one should implement a generic "wait for blocking things". Well, it
>>> does exist and it is called Activity, which provides the interface to
>>> implement whatever policy you want on top of it.
>>>
>>> Then FileDescriptorActivity is such a policy, which -- as its name
>>> states -- is a specific policy that waits on having data on IO.
>>>
>>> In other words, you're complaining about a bad design in RTT that
>>> *already exists* !
>>
>> You are absolutely right. And I have said so much already twice :-)
>>
>> And if you want to open a Pandora box: I still have a long list of things I
>> personally think are not done correctly in RTT for the time being. :-)
>
> Well, it's an open source project. Go fix them then ... I'm sure we'd all
> welcome the contributions.
I do hope so! But such fundamental design redesigns are not just "patches":
they involve major version updates. And thorough discussions.
But stay tuned, I hope these things will spill out of the "best practices"
project BRICS.
> S