Re: Looking for a mechanism (boost::asio

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Looking for a mechanism (boost::asio

Boost - Users mailing list

OK,

 

I’ve just read the preamble for the ASIO library (Chapter 32) and it seems that this library, whilst extremely useful, does exactly the opposite of what I’m trying to achieve, as it allows main code execution to continue whilst waiting for a response from an external device.

 

I need my main code to pause until I receive a response from the hardware. I don’t want to use a timer, as this would be potentially unreliable - I can never know how long a pause would be required and there would be the danger of having the code hanging around wasting time if the timer value is too generous.

 

Best wishes.

 

Tim Burgess

 

From: Boost-users <[hidden email]> On Behalf Of Tim Burgess via Boost-users
Sent: 14 September 2018 20:49
To: [hidden email]
Cc: [hidden email]
Subject: Re: [Boost-users] Looking for a mechanism

 

Thanks – I’ll go and do some reading.

 

Just to add more information: the hardware is a MIDI device, with the sent messages being groups of 6 individual short MIDI messages, so a total of 18 7-bit bytes per transmitted query. The response messages are groups of 4 MIDI short messages. There is something like 200 parameters to be queried – the MIDI connection is either via traditional DIN cables with a transfer rate of 31kbps, or over USB. Over the USB connection the manufacturer estimates that I should be able to get a full set of responses back in around 100ms. I’m using the rtMIDI library to do the heavy lifting in terms of handling the MIDI I/O devices and handling themessage formatting.

 

Best wishes.

 

Tim Burgess

 

From: Boost-users <[hidden email]> On Behalf Of Keith Bennett via Boost-users
Sent: 14 September 2018 18:54
To: [hidden email]
Cc: Keith Bennett <[hidden email]>
Subject: Re: [Boost-users] Looking for a mechanism

 

Without more information it'd be hard to say. Are you familiar with Boost ASIO? It's a common method of handling asynchronous communication, though how much it can be used in your situation may depend on the particular hardware interface.

The typical situation for a single-threaded process is to set up an executor context, maybe set up signal handlers, then make an asynchronous call using ASIO's objects. When making the asynchronous calls, you provide a callback function object. Your callback function object may then make another request during its processing. ASIO handles the under-the-hood abstraction (and generally simplifies it for most situations). But it's up to you to ensure that your call sequence is safe: for example ASIO will not prevent you from making multiple simultaneous writes to the same file descriptor despite it being unsafe in many situations.

My understanding is that your callback is placed onto a function queue rather than called directly (contrast to POSIX signals where the OS interrupts whatever function is running right now). That can hurt your response performance if you're doing long-running tasks so it's worth considering.

 

On Fri, Sep 14, 2018 at 12:03 PM Tim Burgess via Boost-users <[hidden email]> wrote:

Hi,

 

I’m trying to find a method of solving the problem detailed below using Boost (or an alternative:

 

1 – I have to send a series of messages to a hardware device to query its internal parameter values at application load-time. This I can do;

 

2 – I have a callback that receives responses from the hardware, though I get some replies go missing due to saturation;

3

  • The hardware manufacturer tells me that I should send 1 query then wait for the response before sending the next query. I could use Sleep, but this depends on a specific wait time and I’m not sure if it suspends all processing, including my callback, so this doesn’t look satisfactory.

What I’m looking for is a “wait until response” kind of thing, but I haven’t found such a thing so far, though I have found several wait routines for handling multiple threads.

 

I’d appreciate any guidance as to what to look for, as my searches are obviously not asking the right questions.

 

Best wishes.

 

Tim Burgess

Raised Bar Ltd.

E: [hidden email]

M: +44 (0)7989 486976

 

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users



--

Keith Bennett


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Looking for a mechanism (boost::asio

Boost - Users mailing list
On Fri, Sep 14, 2018 at 5:22 PM Tim Burgess via Boost-users
<[hidden email]> wrote:
>
> OK,
>
> I’ve just read the preamble for the ASIO library (Chapter 32) and it seems that this library, whilst extremely useful, does exactly the opposite of what I’m trying to achieve, as it allows main code execution to continue whilst waiting for a response from an external device.

You sure about that? It's typically considered best practice to farm
I/O out to threads, let them do the work, and report back
asynchronously to callbacks, or in this case, signals, etc, in some
way, shape, or form.

> I need my main code to pause until I receive a response from the hardware. I don’t want to use a timer, as this would be potentially unreliable - I can never know how long a pause would be required and there would be the danger of having the code hanging around wasting time if the timer value is too generous.

All the more reason; farm it out to a worker thread, etc, and let it
resolve asynchronously.

Beyond that, not really a Boost question, per se; it's between your
code and that of  the vendor as to what constitutes a completed
request/reply or command/response.

> Best wishes.
>
>
>
> Tim Burgess
>
>
>
> From: Boost-users <[hidden email]> On Behalf Of Tim Burgess via Boost-users
> Sent: 14 September 2018 20:49
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: [Boost-users] Looking for a mechanism
>
>
>
> Thanks – I’ll go and do some reading.
>
>
>
> Just to add more information: the hardware is a MIDI device, with the sent messages being groups of 6 individual short MIDI messages, so a total of 18 7-bit bytes per transmitted query. The response messages are groups of 4 MIDI short messages. There is something like 200 parameters to be queried – the MIDI connection is either via traditional DIN cables with a transfer rate of 31kbps, or over USB. Over the USB connection the manufacturer estimates that I should be able to get a full set of responses back in around 100ms. I’m using the rtMIDI library to do the heavy lifting in terms of handling the MIDI I/O devices and handling themessage formatting.
>
>
>
> Best wishes.
>
>
>
> Tim Burgess
>
>
>
> From: Boost-users <[hidden email]> On Behalf Of Keith Bennett via Boost-users
> Sent: 14 September 2018 18:54
> To: [hidden email]
> Cc: Keith Bennett <[hidden email]>
> Subject: Re: [Boost-users] Looking for a mechanism
>
>
>
> Without more information it'd be hard to say. Are you familiar with Boost ASIO? It's a common method of handling asynchronous communication, though how much it can be used in your situation may depend on the particular hardware interface.
>
> The typical situation for a single-threaded process is to set up an executor context, maybe set up signal handlers, then make an asynchronous call using ASIO's objects. When making the asynchronous calls, you provide a callback function object. Your callback function object may then make another request during its processing. ASIO handles the under-the-hood abstraction (and generally simplifies it for most situations). But it's up to you to ensure that your call sequence is safe: for example ASIO will not prevent you from making multiple simultaneous writes to the same file descriptor despite it being unsafe in many situations.
>
> My understanding is that your callback is placed onto a function queue rather than called directly (contrast to POSIX signals where the OS interrupts whatever function is running right now). That can hurt your response performance if you're doing long-running tasks so it's worth considering.
>
>
>
> On Fri, Sep 14, 2018 at 12:03 PM Tim Burgess via Boost-users <[hidden email]> wrote:
>
> Hi,
>
>
>
> I’m trying to find a method of solving the problem detailed below using Boost (or an alternative:
>
>
>
> 1 – I have to send a series of messages to a hardware device to query its internal parameter values at application load-time. This I can do;
>
>
>
> 2 – I have a callback that receives responses from the hardware, though I get some replies go missing due to saturation;
>
> 3
>
> The hardware manufacturer tells me that I should send 1 query then wait for the response before sending the next query. I could use Sleep, but this depends on a specific wait time and I’m not sure if it suspends all processing, including my callback, so this doesn’t look satisfactory.
>
> What I’m looking for is a “wait until response” kind of thing, but I haven’t found such a thing so far, though I have found several wait routines for handling multiple threads.
>
>
>
> I’d appreciate any guidance as to what to look for, as my searches are obviously not asking the right questions.
>
>
>
> Best wishes.
>
>
>
> Tim Burgess
>
> Raised Bar Ltd.
>
> E: [hidden email]
>
> M: +44 (0)7989 486976
>
>
>
> _______________________________________________
> Boost-users mailing list
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
>
> --
>
> Keith Bennett
>
> _______________________________________________
> Boost-users mailing list
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Looking for a mechanism (boost::asio

Boost - Users mailing list
In reply to this post by Boost - Users mailing list

I need my main code to pause until I receive a response from the hardware. 


ASIO I/O objects (ports, sockets, etc.) support both synchronous and asynchronous variants. E.g., serial_port has both async_read_some and read_some (which does what you want).


Though synchronous I/O with ASIO is clunky [1] as sooner or later you'll need a timeout. (E.g., what should the application do if the hardware never responds, e.g. due to a broken wire?)


[1] Except if you're on Windows where you have CancelSynchronousIO that you can call from another thread. On Linux you could use a signal (pthread_kill) to interrupt a waiting i/o, but that's a can of worms.


From: Boost-users <[hidden email]> on behalf of Tim Burgess via Boost-users <[hidden email]>
Sent: Friday, September 14, 2018 11:21:50 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [Boost-users] Looking for a mechanism (boost::asio
 

OK,

 

I’ve just read the preamble for the ASIO library (Chapter 32) and it seems that this library, whilst extremely useful, does exactly the opposite of what I’m trying to achieve, as it allows main code execution to continue whilst waiting for a response from an external device.

 

I need my main code to pause until I receive a response from the hardware. I don’t want to use a timer, as this would be potentially unreliable - I can never know how long a pause would be required and there would be the danger of having the code hanging around wasting time if the timer value is too generous.

 

Best wishes.

 

Tim Burgess

 

From: Boost-users <[hidden email]> On Behalf Of Tim Burgess via Boost-users
Sent: 14 September 2018 20:49
To: [hidden email]
Cc: [hidden email]
Subject: Re: [Boost-users] Looking for a mechanism

 

Thanks – I’ll go and do some reading.

 

Just to add more information: the hardware is a MIDI device, with the sent messages being groups of 6 individual short MIDI messages, so a total of 18 7-bit bytes per transmitted query. The response messages are groups of 4 MIDI short messages. There is something like 200 parameters to be queried – the MIDI connection is either via traditional DIN cables with a transfer rate of 31kbps, or over USB. Over the USB connection the manufacturer estimates that I should be able to get a full set of responses back in around 100ms. I’m using the rtMIDI library to do the heavy lifting in terms of handling the MIDI I/O devices and handling themessage formatting.

 

Best wishes.

 

Tim Burgess

 

From: Boost-users <[hidden email]> On Behalf Of Keith Bennett via Boost-users
Sent: 14 September 2018 18:54
To: [hidden email]
Cc: Keith Bennett <[hidden email]>
Subject: Re: [Boost-users] Looking for a mechanism

 

Without more information it'd be hard to say. Are you familiar with Boost ASIO? It's a common method of handling asynchronous communication, though how much it can be used in your situation may depend on the particular hardware interface.

The typical situation for a single-threaded process is to set up an executor context, maybe set up signal handlers, then make an asynchronous call using ASIO's objects. When making the asynchronous calls, you provide a callback function object. Your callback function object may then make another request during its processing. ASIO handles the under-the-hood abstraction (and generally simplifies it for most situations). But it's up to you to ensure that your call sequence is safe: for example ASIO will not prevent you from making multiple simultaneous writes to the same file descriptor despite it being unsafe in many situations.

My understanding is that your callback is placed onto a function queue rather than called directly (contrast to POSIX signals where the OS interrupts whatever function is running right now). That can hurt your response performance if you're doing long-running tasks so it's worth considering.

 

On Fri, Sep 14, 2018 at 12:03 PM Tim Burgess via Boost-users <[hidden email]> wrote:

Hi,

 

I’m trying to find a method of solving the problem detailed below using Boost (or an alternative:

 

1 – I have to send a series of messages to a hardware device to query its internal parameter values at application load-time. This I can do;

 

2 – I have a callback that receives responses from the hardware, though I get some replies go missing due to saturation;

3

  • The hardware manufacturer tells me that I should send 1 query then wait for the response before sending the next query. I could use Sleep, but this depends on a specific wait time and I’m not sure if it suspends all processing, including my callback, so this doesn’t look satisfactory.

What I’m looking for is a “wait until response” kind of thing, but I haven’t found such a thing so far, though I have found several wait routines for handling multiple threads.

 

I’d appreciate any guidance as to what to look for, as my searches are obviously not asking the right questions.

 

Best wishes.

 

Tim Burgess

Raised Bar Ltd.

E: [hidden email]

M: +44 (0)7989 486976

 

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users



--

Keith Bennett


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Looking for a mechanism (boost::asio

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On 09/14/18 23:21, Tim Burgess via Boost-users wrote:

> I need my main code to pause until I receive a response from the
> hardware. I don’t want to use a timer, as this would be potentially

Sounds like you need a promise/future.
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users