TeraBit
Home
Our Solutions / Products
Services
White Papers / Articles
FAQ
License
Success Stories
Enquiries and Feedback
Contact Us
FAQ
Currently I try to implement an asynch file writer via ACE_Asynch_Write_File and the ACE_Proactor, which is listening for completion events in a separate thread spawned via an ACE_Task. Till ACE 5.2.3 my demo worked fine. I tested two different ways dispatch completions at the proactor - handle_event - proactor_run_event_loop Now I tried to migrate to ACE 5.2.4 but my demo does not work anymore. Are there any important changes regarding the proactor in ACE 5.2.4?

The problem that is message block has length = 0 New check was added to 5.2.4

It almost looks like the ACE_Proactor::register_handle() function is not even necessary because the associations are set up in the ACE_Asynch_Read_Stream::open() function. Is this true? If this is true what is the ACE_Proactor::register_handle() function used for?

It is called from ACE_WIN32_Asynch_Operation to assosiate stream/file handle with I/O completion port. On POSIX this method currently is no-op, but can be useful in the future. General idea of this method: to let know Proactor about new handle, before starting any AIO on this handle. Users applications should not call this method.

I was previously working under ACE version 5.2.3 but for some reason the asynch acceptor failed to close down completely even though its destructor was called when the daemon was removed and so kept accepting connections from clients. More problems arise when I try to remove the service. fini() is called but the asynch acceptor that was invoked in the svc() method by the daemon is not destroyed. Unlike the similar problem I ran into before, the destructor for the acceptor is not called. Client connections are constantly accepted.

The reason is that your aplication still has pending AIO requests (real AIO requests - read/write and pseudo AIO requests - asynch accepts) at the moment when you want to unload service. To avoid this you always should guarantee that there is no pending AIO requests. Best way is to support reference count of pending operations. When count is zero, it save to destroy your objects - Asynch_Acceptor and ACE_Handlers.

I tired sending a packet and got:
"POSIX_Proactor.cpp:1634:(10178 | 1)::sig_handler received signal: 38"

By default you are using POSIX_SIG_Proactor implementation. For SIG type Proactor you should disable following signals : ACE_SIGRTMIN,...,ACE_SIGRTMAX in all threads of the process (example in ACE_wrappers/tests/Proactor_Test.cpp)

Proactor_Timer_Test fails thusly: Running Proactor_Timer_Test
Jul 19 01:01:23.769 2002@LM_DEBUG@ACE_POSIX_AIOCB_Proactor::delete_result_aiocb_list number pending AIO=1
Jul 19 01:01:23.769 2002@LM_ERROR@Proactor.cpp:532:(28496 | 1024):ACE_Proactor::close:implementation couldnt be closed: No such file or directory

It is well know problem explained by Linux AIO implementation - it does not handle sockets well. Proactor is not able to cancel outstanding AIO request - aio_cancel() returns AIO_NOTCANCELLED. Behavior of close() depends on implemntation and close()can wait for AIO completion also ( 2 hours for TCP/IP ) This is problem disappeared with new Proactor.

Copyright © 2003-06 TeraBit P/L. All Rights Reserved.