Inter-Process Signalling with "unlimited" processes?
-
Hi everyone, I have "unlimited" processes (let's say 5 to 20 is a realistic number) What I need is the following: From time to time one of the processes has to signal the others that they have something to do. There is no master, so I won't create some server which passes arround events for all interested processes. There is also no message/content, so I would favor some low-level signalling. But without a master process IPC is not very handy at all. WaitEventHandle seemed to be a good choice; even though it also works on process-level, it does not always work properly. Every listening process has a thread whichs calls WaitOne(); when the event is sent it starts some action, calls Reset() and loops back to WaitOne(). The process which wants to indicate something creates a WaitEventHandle with the same name and calls Set(). In a simple hello world application this worked pretty well; but in some other application exactly the same approach never passes the second WaitOne(). Just as if noone would call Set anymore (but the other process still does!) Is there any other useful low-level signalling? I am also not happy about the background thread with the do-while around the WaitOne(). Why are there no monitors or counters that simply fire an event when some equally named object in a different process/thread raises an event. :p Cheerio, Roland
-
Hi everyone, I have "unlimited" processes (let's say 5 to 20 is a realistic number) What I need is the following: From time to time one of the processes has to signal the others that they have something to do. There is no master, so I won't create some server which passes arround events for all interested processes. There is also no message/content, so I would favor some low-level signalling. But without a master process IPC is not very handy at all. WaitEventHandle seemed to be a good choice; even though it also works on process-level, it does not always work properly. Every listening process has a thread whichs calls WaitOne(); when the event is sent it starts some action, calls Reset() and loops back to WaitOne(). The process which wants to indicate something creates a WaitEventHandle with the same name and calls Set(). In a simple hello world application this worked pretty well; but in some other application exactly the same approach never passes the second WaitOne(). Just as if noone would call Set anymore (but the other process still does!) Is there any other useful low-level signalling? I am also not happy about the background thread with the do-while around the WaitOne(). Why are there no monitors or counters that simply fire an event when some equally named object in a different process/thread raises an event. :p Cheerio, Roland
Is it a requirement that there is no server? I would create a hub service (whether as an actual service or just an app which gets started with any process if it isn't already up) which each process connected to over TCP, and then you can use classic client/server notification and broadcasting. Peer-to-peer networks are notoriously a pain and that's essentially what you're suggesting, even if all the processes are on the same machine. (The other big bonus of using TCP and a hub process is that it makes it really easy to scale the problem to several machines in future.)
-
Is it a requirement that there is no server? I would create a hub service (whether as an actual service or just an app which gets started with any process if it isn't already up) which each process connected to over TCP, and then you can use classic client/server notification and broadcasting. Peer-to-peer networks are notoriously a pain and that's essentially what you're suggesting, even if all the processes are on the same machine. (The other big bonus of using TCP and a hub process is that it makes it really easy to scale the problem to several machines in future.)
It's actually really a requirement. We are working on local machine only (also in the future) and want to avoid the network stack. As mentioned before, we only need some trigger, there is no information to transfer. If we'd be using the network stack anyhow, I'd reather prefer to broadcast something on UDP instead of starting some server/hub along with the first process. :) But since it is really just a trigger without any content, I cannot imagine that there is no simple signalling on OS-level...? Although, maybe there is really nothing. :sigh:
-
It's actually really a requirement. We are working on local machine only (also in the future) and want to avoid the network stack. As mentioned before, we only need some trigger, there is no information to transfer. If we'd be using the network stack anyhow, I'd reather prefer to broadcast something on UDP instead of starting some server/hub along with the first process. :) But since it is really just a trigger without any content, I cannot imagine that there is no simple signalling on OS-level...? Although, maybe there is really nothing. :sigh:
Well, if you don't like the Wait On Event solution (come on, that has to work, everybody uses it) and you don't want to use network functions, the only other thing I can think of is file change notifications or registry change notifications.
-
Hi everyone, I have "unlimited" processes (let's say 5 to 20 is a realistic number) What I need is the following: From time to time one of the processes has to signal the others that they have something to do. There is no master, so I won't create some server which passes arround events for all interested processes. There is also no message/content, so I would favor some low-level signalling. But without a master process IPC is not very handy at all. WaitEventHandle seemed to be a good choice; even though it also works on process-level, it does not always work properly. Every listening process has a thread whichs calls WaitOne(); when the event is sent it starts some action, calls Reset() and loops back to WaitOne(). The process which wants to indicate something creates a WaitEventHandle with the same name and calls Set(). In a simple hello world application this worked pretty well; but in some other application exactly the same approach never passes the second WaitOne(). Just as if noone would call Set anymore (but the other process still does!) Is there any other useful low-level signalling? I am also not happy about the background thread with the do-while around the WaitOne(). Why are there no monitors or counters that simply fire an event when some equally named object in a different process/thread raises an event. :p Cheerio, Roland
Don Rolando wrote:
In a simple hello world application this worked pretty well; but in some other application exactly the same approach never passes the second WaitOne(). Just as if noone would call Set anymore (but the other process still does!)
I bet you were doing work in there. Do this instead. 1. Create a thread safe notify queue (just a queue which moves a flag) 2. Create a thread that does NOTHING but wait for the notification and post to the queue. For safety use a timeout. 3. Create another thread that does the work. It does the work when something shows up on the queue. You can implement 1/2 completely independently from the real version of 3 using whatever simulated work load you want.
-
Don Rolando wrote:
In a simple hello world application this worked pretty well; but in some other application exactly the same approach never passes the second WaitOne(). Just as if noone would call Set anymore (but the other process still does!)
I bet you were doing work in there. Do this instead. 1. Create a thread safe notify queue (just a queue which moves a flag) 2. Create a thread that does NOTHING but wait for the notification and post to the queue. For safety use a timeout. 3. Create another thread that does the work. It does the work when something shows up on the queue. You can implement 1/2 completely independently from the real version of 3 using whatever simulated work load you want.
jschell wrote:
I bet you were doing work in there.
You are right, I did. For testing purpose I was calling a dispatcher to show in the UI that the EventWaitHandle's thread received the signal. When removing the line with the dispatcher call, it works. Ahm, but why does the dispatcher corrupt the whole EventWaitHandler? To be honest, your suggested approach is also some kind of custom dispatcher, isn't it? Could you enlight me why this has influence on the EventWaitHandle at all?
-
jschell wrote:
I bet you were doing work in there.
You are right, I did. For testing purpose I was calling a dispatcher to show in the UI that the EventWaitHandle's thread received the signal. When removing the line with the dispatcher call, it works. Ahm, but why does the dispatcher corrupt the whole EventWaitHandler? To be honest, your suggested approach is also some kind of custom dispatcher, isn't it? Could you enlight me why this has influence on the EventWaitHandle at all?