Hi all
Do the routines handling an IPC Message (sent by SendIPCMessage) run in their own thread?
Is it a queuing system, i.e. are they processed sequentially when the 'same' IPC messages come in rapid succession?
I'm asking this because my service, which contains the IPC message handlers, does a Sleep(3000) at the end of its ServiceExecute.
I have the impression that IPC messages are not coming through during that time.
If so, what would be a way to still 'listen' to the IPC messages during that interval?
Thanks
Jan
Is handling IPC messages threaded and queued?
I'm not 100% sure about what exactly you are describing but I have a service which responds to several IPC channels without issue.
Firstly, although Madshi's documentation *suggests* that the IPC callback is threaded, I have spawned a separate thread for each IPC channel.
Secondly, it is not a good idea to use Sleep() pretty much anywhere - and certainly not within your ServiceExecute. When you call Sleep(), you are wasting valuable process time - if you read into Windows threading and multitasking model, you will see that even when Sleep() is called, you are still effectively using process time. It is much better to create an kernel Event Object and use something like WaitForSingleObject() - but this is dependent on your individual service model.
In the past I used Sleep() alot - not I never do it and my code seems much more efficient.
HTH Mike C
Firstly, although Madshi's documentation *suggests* that the IPC callback is threaded, I have spawned a separate thread for each IPC channel.
Secondly, it is not a good idea to use Sleep() pretty much anywhere - and certainly not within your ServiceExecute. When you call Sleep(), you are wasting valuable process time - if you read into Windows threading and multitasking model, you will see that even when Sleep() is called, you are still effectively using process time. It is much better to create an kernel Event Object and use something like WaitForSingleObject() - but this is dependent on your individual service model.
In the past I used Sleep() alot - not I never do it and my code seems much more efficient.
HTH Mike C
I found out that different IPC handlers can run concurrently, as long as I make sure they 'have' their 'own' data. This does not answer if they are threaded though 
Also I have not seen 'nested calls' i.e. an IPC handler getting called while it is processing (and one of them is called *frequently*). It looks as if they are queued but that is not a definitive answer. The PC may be just too quick.
Madshi, if you have the answers that would be great
Also I have not seen 'nested calls' i.e. an IPC handler getting called while it is processing (and one of them is called *frequently*). It looks as if they are queued but that is not a definitive answer. The PC may be just too quick.
Madshi, if you have the answers that would be great
Not sure why you're using Sleep, but I don't think it should stop IPC from working.
IPC callbacks are fully threaded. When calling CreateIpcQueueEx you can specify how much threads madCodeHook is allowed to use max for the new IPC queue. Of course if all threads are busy waiting for an IPC answer, the IPC queue can't process further IPC messages.
IPC callbacks are fully threaded. When calling CreateIpcQueueEx you can specify how much threads madCodeHook is allowed to use max for the new IPC queue. Of course if all threads are busy waiting for an IPC answer, the IPC queue can't process further IPC messages.