Re: IPC and Threading in DLL

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

If you need to arbitate between client apps, a service is probably best (it is possible in a driver, but its easier to keep this arbitration in user mode), but if you just need to allow access to the device without any arbitration then a driver may be needed (depends on the device)

Non-driver services just cannot communicate with the hardware, ...

They can, but using the same CreateFile / DeviceIoControl / ReadFile / WriteFile mechamisms that a standalone app can use.


On Fri, 20 Apr 2007 02:14:03 +0100, Anton Bassov <AntonBassov@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

I would rather write a service to communicate with the hardware, and
have each client process communicate with this service through an IPC
mechanism (socket, pipe, shared memory, whatever....).

Non-driver services just cannot communicate with the hardware, so that you
would have to write a driver, and, at this point, there would be no need for
any form of IPC - just CreateFile() and DeviceIoControl(). Furthermore, out
of all things that you have mentioned the only one that applies to app-driver
communication is shared memory. However, normally this is not the best
option, unless you need to transfer *HUGE* amounts of data at high
frequency......

Anton Bassov

"adebaene@xxxxxxxxxxxxxxxx" wrote:

On Apr 17, 9:29 am, Ezmeralda <ezmera...@xxxxxx> wrote:
> Hello,
>
> I have the following application requirements:
>
> I need to have one DLL which may be used by several
> processes at the same time. This DLL should communicate
> to hardware and make the hardware available to all
> the processes connected to the DLL.
>
> I have the following design idea in mind:
> - the first process connecting to the DLL starts a
> thread in DllMain() (DLL_PROCESS_ATTACH) which
> communicates to the hardware and puts data in
> a global shared section
> - all other processes connecting to the DLL do
> not start a thread but can access the data in
> the global section
> - when the last proccess detaches from the DLL,
> the communication-thread should be terminated

As Gary has explained, this can't work because the communication
thread is bound to the 1st process that uses the DLL, and that process
may exit before others.

I would rather write a service to communicate with the hardware, and
have each client process communicate with this service through an IPC
mechanism (socket, pipe, shared memory, whatever....). This IPC
mechanism should be encapsulated within a DLL loaded by the clients.

The service runs all the time (even when nobody is logged), and it can
arbitrate among several concurrent and/or incopatible requests from
various clients.

Arnaud
MVP - VC





--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
.

Relevant Pages

  • Re: screen scrape / remote manipulation
    ... Functionally a dll is no different from an .exe in terms of spying ... The other option is to install software capable of monitoring TCP/IP port ... connection is established between the dll (on the client) and the server, ...
    (microsoft.public.windowsxp.general)
  • Re: VB6 Winsock action on Server
    ... separate dll instance for each client request process it, ... of your 'dll' (assuming it is an ActiveX-Dll? ...
    (microsoft.public.vb.general.discussion)
  • Re: VB6 Winsock action on Server
    ... file the dll must access. ... No one client request is related to any other. ... server could not possibly utilize the capabilities of the additional ...
    (microsoft.public.vb.general.discussion)
  • RE: SoapHttpClientProtocol request canceled
    ... Since this is only happening on the VB client, is there any chance that the ... The VB.NET exe and the VB6 exe both use VB.NET dll to sent request/response ... > inputHeaderer, String messageControlPayload, string inputMessage) ... > Imports System.ComponentModel ...
    (microsoft.public.dotnet.framework.webservices)
  • Re: question about ip addresses
    ... You are using a program to communicate to someone ... a client program, and one is the server program. ... This is neither unreasonable, nor a security issue. ... provider, your country, and likely one can deduce some more accurate ...
    (alt.computer.security)