Background processing in service dll

[coder]

Hi, We are developing a service dll for WM6 Pro platform with VS2008 which
is going do some networkmonitoring, http request tasks etc. Multiple clients
apps could make use of
the service. As the tasks requested by clients are essentially asynchronous
we have come up with the following architecture. Client will send a task
request with ServiceIoctl, The service
itself when it's XXX_Init entry point is called creates a Worker thread with
a windows message loop. When it receives an Ioctl it creates a 'task
'object and PostMessage's it to the Worker thread which deals with it. Upon
completion of the task we send a windows message back to the client app that
called the Ioctl notifying of success or failure etc. The windows handle to
the client app will be sent in the Ioctl call so the service knows who to
respond to.

If its a synchronous task the Ioctl handler will SendMessage(Timeout?) to
the worker thread.
Any response can be sent back in the Ioctl parameters in this case.

Can anyone see any flaws in this architecture or areas for improvement?

thanks

__________ Information from ESET Smart Security, version of virus signature database 4161 (20090617) __________

The message was checked by ESET Smart Security.

http://www.eset.com

[Chris Tacke, eMVP]

I certainly wouldn't use Windows Messages for this. You could theoretically
cross the Atlantic in a kayak - doesn't mean it's a good idea.

--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

"coder" <co...@hotmail.com> wrote in message
news:%23c$g9Lz7J...@TK2MSFTNGP04.phx.gbl...

[coder]

Did you mean don't use Windows messages to signal back to the client app
from the service
or don't use them within the service to allow async processing on the worker
thread.

OR both maybe?

"Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
news:Oc8cLV17...@TK2MSFTNGP03.phx.gbl...

> signature database 4162 (20090617) __________

>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
>

__________ Information from ESET Smart Security, version of virus signature database 4162 (20090617) __________

[coder]

Fair enough, in this case my main worker thread in the service needs to have
a
message pump as it will be handling windows messages from the system eg
Connection Manager notifications so i have this anyway. So am not sure
what else to use for cross thread comms in this case. If i have a windows
message loop i can't wait on events as well can I ? ie in my service worker
thread.

For transporting data we were going to use the wparam field to pass in a
pointer
to small datastruct ie the ioctl handler would create this object and send
it across
for executioon on the worker. unfortunately we would need to cleanup on the
otherside
of the thread boundary in the case of PostMessage.

"Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message

news:uDSZvB27...@TK2MSFTNGP03.phx.gbl...
>I wouldn't use it for either. Windows Messages are slow, they require the
>client to actually have a message pump, they are a pain for transferring
>anything beyone 32-bit numbers and they suck for cross-thread comms.

>
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded community
> http://community.OpenNETCF.com
>
>
> "coder" <co...@hotmail.com> wrote in message

> news:eXqAn317...@TK2MSFTNGP05.phx.gbl...

[Chris Tacke, eMVP]

I wouldn't use it for either. Windows Messages are slow, they require the
client to actually have a message pump, they are a pain for transferring
anything beyone 32-bit numbers and they suck for cross-thread comms.

--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

"coder" <co...@hotmail.com> wrote in message

news:eXqAn317...@TK2MSFTNGP05.phx.gbl...

[Paul G. Tobey [eMVP]]

A point-to-point message queue is easy to use for sending data of various
sizes from process to process. Look up CreateMsgQueue(), ReadMsgQueue(),
WriteMsgQueue(), etc. You could layer your own API over these things, if
you want to provide the "other" application with a simpler interface that's
not so completely connected to your actual architecture (SendMsgToService(
param1, param2, param3 ), etc.)

As for notifying the application back that something is done, how to do it
depends on what form the notification takes. If you have to return data,
another message queue, facing the other directions (queues are one-way),
would be possible. If not, a simple OS-level event, CreateEvent(),
WaitForSingleObject(), etc. is a good way to go.

Paul T.

"coder" <co...@hotmail.com> wrote in message

news:eyF8kJ27...@TK2MSFTNGP05.phx.gbl...