Problem using ACE_Task::putq/getq with timeouts
Stanford S. Guillory
On NT, whenever I call ACE_Task::putq() or ACE_Task::getq() with
a timeout value, such as:
MyACETask::svc()
{
ACE_Time_Value tv;
while (1) {
tv.sec(5);
// Get the message...
int ret = this->getq(message);
if (ret == -1) {
if (errno == EWOULDBLOCK) {
trace("Dispatcher's service method timed out. Calling
getq.");
continue;
}
// handle more serious error
}
. . .
The call to getq() returns immediately, so that I have a tight loop that
pegs
the CPU. Has anyone else had this problem? I use TimeValues with
ACE_OS::select, and with the Reactor::handle_input() method, and it
works as I would expect.
Thanks,
Stanford S. Guillory
Vignette Corporation
guil...@vignette.com
Steve Huston
>
> On NT, whenever I call ACE_Task::putq() or ACE_Task::getq() with
> a timeout value, such as:
>
> MyACETask::svc()
> {
> ACE_Time_Value tv;
> while (1) {
> tv.sec(5);
> // Get the message...
> int ret = this->getq(message);
> if (ret == -1) {
> if (errno == EWOULDBLOCK) {
> trace("Dispatcher's service method timed out. Calling
> getq.");
> continue;
> }
> // handle more serious error
> }
> . . .
>
> The call to getq() returns immediately, so that I have a tight loop that
> pegs
> the CPU. Has anyone else had this problem? I use TimeValues with
> ACE_OS::select, and with the Reactor::handle_input() method, and it
> works as I would expect.
Problem 1: You didn't pass tv to getq above
Problem 2: The time value is absolute time in this case. It isn't clear
from the man page, so I'll clarify that. You'll need to do something
like this:
ACE_Time_Value tv(ACE_OS::gettimeofday() + 5);
this->getq (message, &tv);
-Steve
--
Steve Huston Riverace Corporation
Email: shu...@riverace.com http://www.riverace.com
Specializing in TCP/IP, CORBA, ACE (508) 541-9183, FAX 541-9185
Expertise to help your projects succeed We support ACE!
Stanford S. Guillory
Steve Huston wrote:
> Stanford S. Guillory wrote:
> > ACE_Time_Value tv;
> > while (1) {
> > tv.sec(5);
> > // Get the message...
> > int ret = this->getq(message);
> > . . .
> >
> Problem 1: You didn't pass tv to getq above
Doh! I copied the above frmo my source, which of course
doesn't pass a time value because I couldn't get it to
work. I understood that much at least. :*)
> Problem 2: The time value is absolute time in this case. It isn't clear
> from the man page, so I'll clarify that. You'll need to do something
> like this:
>
> ACE_Time_Value tv(ACE_OS::gettimeofday() + 5);
> this->getq (message, &tv);
>
Cool. Although now I'm a little concerned about how many different
interpretations of time are there in blocking components of ACE, and how
well documented are they.
Thanks,
Stan
Steve Huston
>
> Steve Huston wrote:
>
> > Stanford S. Guillory wrote:
> > > ACE_Time_Value tv;
> > > while (1) {
> > > tv.sec(5);
> > > // Get the message...
> > > int ret = this->getq(message);
> > > . . .
> > >
> > Problem 1: You didn't pass tv to getq above
>
> Doh! I copied the above frmo my source, which of course
> doesn't pass a time value because I couldn't get it to
> work. I understood that much at least. :*)
I figured you did... I left off the smiley in my first reply by
accident.
> > Problem 2: The time value is absolute time in this case. It isn't clear
> > from the man page, so I'll clarify that. You'll need to do something
> > like this:
> >
> > ACE_Time_Value tv(ACE_OS::gettimeofday() + 5);
> > this->getq (message, &tv);
> >
>
> Cool. Although now I'm a little concerned about how many different
> interpretations of time are there in blocking components of ACE, and how
> well documented are they.
Well, there are only 2 - absolute and relative ;-)
They tend to follow how the underlying OS will treat them (or how most
common facilities treat them). So select uses relative, threads-related
things are generally absolute. It gets murky sometimes in the higher
levels of abstraction - like message queue ;-) Docs are always
improved, though, when the deficiency is noticed.
Take care,
Steve Huston
> Problem 2: The time value is absolute time in this case. It isn't clear
> from the man page, so I'll clarify that.
It's already clear - I just didn't look at it right - there's a
paragraph introducing the enqueue/dequeue methods which describes the
timeout - is that clear, or if not, what's unclear?
Thanks,
Douglas C. Schmidt
> Cool. Although now I'm a little concerned about how many different
> interpretations of time are there in blocking components of ACE, and
> how well documented are they.
They should all be documented. If you find ones that aren't please
let us know.
Thanks,
Doug
--
Dr. Douglas C. Schmidt, Associate Professor
Department of Computer Science, Washington University
St. Louis, MO 63130. Work #: (314) 935-4215; FAX #: (314) 935-7302
sch...@cs.wustl.edu, www.cs.wustl.edu/~schmidt/
Douglas C. Schmidt
>It's already clear - I just didn't look at it right - there's a
>paragraph introducing the enqueue/dequeue methods which describes the
>timeout - is that clear, or if not, what's unclear?
I suspect that Stan didn't read the intro paragraph. To make things
less confusing I've added a comment about this on each relevant method
in ACE_Task and ACE_Message_Queue. Stan, if there's anywhere else
that needs a comment please let me know.
Douglas C. Schmidt
>On NT, whenever I call ACE_Task::putq() or ACE_Task::getq() with
>a timeout value, such as:
>
>MyACETask::svc()
>{
> ACE_Time_Value tv;
> while (1) {
> tv.sec(5);
> // Get the message...
> int ret = this->getq(message);
> if (ret == -1) {
> if (errno == EWOULDBLOCK) {
> trace("Dispatcher's service method timed out. Calling
>getq.");
> continue;
> }
> // handle more serious error
> }
> . . .
>
>
>The call to getq() returns immediately, so that I have a tight loop that
>pegs
>the CPU. Has anyone else had this problem?
Please read the documentation for getq() and putq() carefully in
Task_T.h:
// For the following five method if <timeout> == 0, the caller will
// block until action is possible, else will wait until the absolute
// time specified in *<timeout> elapses). These calls will return,
// however, when queue is closed, deactivated, when a signal occurs,
// or if the time specified in timeout elapses, (in which case errno
// = EWOULDBLOCK).
Since "absolute" time is used, this means that you'll need to do
something like this:
tv.sec(ACE_OS::gettimeofday () + ACE_Time_Value (5));
BTW, Bob Whirter, this is an ACE "FMM". Could you please add this to
your list when you've got time?
Klaus H. Wolf
HOST MACHINE and OPERATING SYSTEM: PC K6-300, Win95
TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
COMPILER NAME AND VERSION: MS Visual C++ 5.0
AREA/CLASS/EXAMPLE AFFECTED:
Proactor example, ACE\examples\Reactor\Proactor\test_proactor.dsp
SYNOPSIS:
CreateIoCompletionPort fails
DESCRIPTION:
unmodified example compiles, runs, returns the log output below, and
terminates
::CreateIoCompletionPort returns NULL
called by proactor_->register_handle
My config.h for Win95:
#define ACE_HAS_WINNT4 0
#include "ace/config-win32.h"
REPEAT BY:
console log msg:
CreateIoCompletionPort: Not enough space
CreateIoCompletionPort: This function is only valid in Win32 mode.
SAMPLE FIX/WORKAROUND:
[If available ]
Douglas C. Schmidt
> ACE VERSION: 4.6
> HOST MACHINE and OPERATING SYSTEM: PC K6-300, Win95
>CreateIoCompletionPort: This function is only valid in Win32 mode.
As the error message says, I/O completion ports are only valid on
WinNT, not on Win95.
Take care,
Tres Seaver
>
> Hi Klaus,
>
> > ACE VERSION: 4.6
> > HOST MACHINE and OPERATING SYSTEM: PC K6-300, Win95
> >CreateIoCompletionPort: This function is only valid in Win32 mode.
>
> As the error message says, I/O completion ports are only valid on
> WinNT, not on Win95.
Quibble: "Win32" is a description of an API which includes Win95 (although the
_implemenation_ in 95 still has lots of 16 bit cruft, of course); perhaps make
the error message call out "NT" instead?
--
=========================================================
Tres Seaver tse...@palladion.com 713-523-6582
Palladion Software http://www.palladion.com
Douglas C. Schmidt
>> >
>> > > ACE VERSION: 4.6
>> > > HOST MACHINE and OPERATING SYSTEM: PC K6-300, Win95
>> > >CreateIoCompletionPort: This function is only valid in Win32 mode.
>> >
>> > As the error message says, I/O completion ports are only valid on
>> > WinNT, not on Win95.
>>
>> Quibble: "Win32" is a description of an API which includes Win95 (although the
>> _implemenation_ in 95 still has lots of 16 bit cruft, of course); perhaps make
>> the error message call out "NT" instead?
I don't think this error message is coming from ACE, or if it was,
it's not there anymore. If someone can identify where it's coming
from and let us know what to fix, we'll be happy to fix it!
Tres Seaver
>
> Hi Tres,
>
> >> >
> >> > > ACE VERSION: 4.6
> >> > > HOST MACHINE and OPERATING SYSTEM: PC K6-300, Win95
> >> > >CreateIoCompletionPort: This function is only valid in Win32 mode.
> >> >
> >> > As the error message says, I/O completion ports are only valid on
> >> > WinNT, not on Win95.
> >>
> >> Quibble: "Win32" is a description of an API which includes Win95 (although the
> >> _implemenation_ in 95 still has lots of 16 bit cruft, of course); perhaps make
> >> the error message call out "NT" instead?
>
> I don't think this error message is coming from ACE, or if it was,
> it's not there anymore. If someone can identify where it's coming
> from and let us know what to fix, we'll be happy to fix it!
Hmm, the SDK help file sez, "NT Only", but otherwise refers to the "32-bit IO
subsystem." What does that suggest about the IO in Win95?
Still-won't-install-9[58]-on-any-REAL-machine,