VC, Can a thread created in DLL be disassociated from the starting application?

Can a thread created in DLL be disassociated from the starting application?

Author	Message
Brad Pan #1 / 6	Can a thread created in DLL be disassociated from the starting application? I have a DLL which communicates via a socket to an embedded system. This DLL can now support 5 Control clients talking via 1 socket to the 1 embedded system. It supports the 5 clients by making a copy of the message to shared memory inside the DLL and then allowing the Control clients to read these shared messages. However if I exit the first Control client which is the one that creates the threads that handles the reading and writing of the socket, then all communication stops for the other clients. That first one has the Handle to the Threads. I could probably disallow the user from closing that first Client however is it possible to somehow disassociate the Threads from the process that started them?
Sun, 20 Feb 2005 23:56:16 GMT

Igor Tandetni #2 / 6	Can a thread created in DLL be disassociated from the starting application? No. A thread lives in a process. You can implement your communication component as a separate process. -- With best wishes, Igor Tandetnik "For every complex problem, there is a solution that is simple, neat, and wrong." H.L. Mencken Quote: > I have a DLL which communicates via a socket to an embedded system. > This DLL > can now support 5 Control clients talking via 1 socket to the 1 > embedded > system. It supports the 5 clients by making a copy of the message to > shared > memory inside the DLL and then allowing the Control clients to read > these shared messages. > However if I exit the first Control client which is the one that > creates the > threads that handles the reading and writing of the socket, then all > communication stops for the other clients. That first one has the > Handle to the > Threads. > I could probably disallow the user from closing that first Client > however is it > possible to somehow disassociate the Threads from the process that > started them?
Mon, 21 Feb 2005 00:13:18 GMT

Brad Pan #3 / 6	Can a thread created in DLL be disassociated from the starting application? So If I change this DLL to a process, (which to me means an EXE), then don't I lose all the "Visible" function calls that the DLL provides? Thanks for your Help Igor. Quote: > No. A thread lives in a process. You can implement your communication > component as a separate process. > -- > With best wishes, > Igor Tandetnik > "For every complex problem, there is a solution that is simple, neat, > and wrong." H.L. Mencken > > I have a DLL which communicates via a socket to an embedded system. > > This DLL > > can now support 5 Control clients talking via 1 socket to the 1 > > embedded > > system. It supports the 5 clients by making a copy of the message to > > shared > > memory inside the DLL and then allowing the Control clients to read > > these shared messages. > > However if I exit the first Control client which is the one that > > creates the > > threads that handles the reading and writing of the socket, then all > > communication stops for the other clients. That first one has the > > Handle to the > > Threads. > > I could probably disallow the user from closing that first Client > > however is it > > possible to somehow disassociate the Threads from the process that > > started them?
Mon, 21 Feb 2005 08:12:18 GMT

Igor Tandetni #4 / 6	Can a thread created in DLL be disassociated from the starting application? I don't understand your question. -- With best wishes, Igor Tandetnik "For every complex problem, there is a solution that is simple, neat, and wrong." H.L. Mencken Quote: > So If I change this DLL to a process, (which to me means an EXE), then > don't I lose all the "Visible" function calls that the DLL provides? > Thanks for your Help Igor. Quote: > > No. A thread lives in a process. You can implement your communication > > component as a separate process. > > -- > > With best wishes, > > Igor Tandetnik > > "For every complex problem, there is a solution that is simple, neat, > > and wrong." H.L. Mencken > > > I have a DLL which communicates via a socket to an embedded system. > > > This DLL > > > can now support 5 Control clients talking via 1 socket to the 1 > > > embedded > > > system. It supports the 5 clients by making a copy of the message to > > > shared > > > memory inside the DLL and then allowing the Control clients to read > > > these shared messages. > > > However if I exit the first Control client which is the one that > > > creates the > > > threads that handles the reading and writing of the socket, then all > > > communication stops for the other clients. That first one has the > > > Handle to the > > > Threads. > > > I could probably disallow the user from closing that first Client > > > however is it > > > possible to somehow disassociate the Threads from the process that > > > started them?
Mon, 21 Feb 2005 21:39:24 GMT

Brad Pan #5 / 6	Can a thread created in DLL be disassociated from the starting application? Thanks for your input... This DLL is called by my VB application, I make calls like "Connect" in which I pass an IP address to connect to, and then Read_from_Socket, and Write_To_Socket, and Shutdown which closes the Connection. Having this as a DLL allows me to make all of these function calls directly from VB. The C DLL is my path from the VB program and allows me to connect multiple VB clients to one Socket connection to the Embedded system. The question is, if I change this DLL to an Application then I can not make all of these visible DLL function calls, right? Instead I would have to change it to be a server which would make Socket connections to the VB programs and then a Socket connection to the Embedded system. Or asked differently, is there any way to have a Visible function call like a C DLL provides in an EXE type application? I have been programming for about ten years now but I don't think that having visible function calls (to a VB program) in an Application is possible...but let me know. Quote: > I don't understand your question. > -- > With best wishes, > Igor Tandetnik > "For every complex problem, there is a solution that is simple, neat, > and wrong." H.L. Mencken > > So If I change this DLL to a process, (which to me means an EXE), then > > don't I lose all the "Visible" function calls that the DLL provides? > > Thanks for your Help Igor. > > > No. A thread lives in a process. You can implement your > communication > > > component as a separate process. > > > -- > > > With best wishes, > > > Igor Tandetnik > > > "For every complex problem, there is a solution that is simple, > neat, > > > and wrong." H.L. Mencken > > > > I have a DLL which communicates via a socket to an embedded > system. > > > > This DLL > > > > can now support 5 Control clients talking via 1 socket to the 1 > > > > embedded > > > > system. It supports the 5 clients by making a copy of the message > to > > > > shared > > > > memory inside the DLL and then allowing the Control clients to > read > > > > these shared messages. > > > > However if I exit the first Control client which is the one that > > > > creates the > > > > threads that handles the reading and writing of the socket, then > all > > > > communication stops for the other clients. That first one has the > > > > Handle to the > > > > Threads. > > > > I could probably disallow the user from closing that first Client > > > > however is it > > > > possible to somehow disassociate the Threads from the process that > > > > started them?
Tue, 22 Feb 2005 10:24:49 GMT

Igor Tandetni #6 / 6	Can a thread created in DLL be disassociated from the starting application? You can make your application an out-of-proc COM server, in which case COM will take care of the details of communicating between VB app and your app. Or, you can write a DLL and an EXE server. VB app calls methods in a DLL, which communicates with the EXE using whichever IPC mechanism you prefer. -- With best wishes, Igor Tandetnik "For every complex problem, there is a solution that is simple, neat, and wrong." H.L. Mencken Quote: > Thanks for your input... > This DLL is called by my VB application, I make calls like "Connect" > in which I pass an IP address to connect to, and then > Read_from_Socket, and Write_To_Socket, and Shutdown which closes the > Connection. Having this as a DLL allows me to make all of these > function calls directly from VB. The C DLL is my path from the VB > program and allows me to connect multiple VB clients to one Socket > connection to the Embedded system. > The question is, if I change this DLL to an Application then I can not > make all of these visible DLL function calls, right? > Instead I would have to change it to be a server which would make > Socket connections to the VB programs and then a Socket connection to > the Embedded system. > Or asked differently, is there any way to have a Visible function call > like a C DLL provides in an EXE type application? > I have been programming for about ten years now but I don't think that > having visible function calls (to a VB program) in an Application is > possible...but let me know. - Hide quoted text - - Show quoted text - Quote: > > I don't understand your question. > > -- > > With best wishes, > > Igor Tandetnik > > "For every complex problem, there is a solution that is simple, neat, > > and wrong." H.L. Mencken > > > So If I change this DLL to a process, (which to me means an EXE), then > > > don't I lose all the "Visible" function calls that the DLL provides? > > > Thanks for your Help Igor. > > > > No. A thread lives in a process. You can implement your > > communication > > > > component as a separate process. > > > > -- > > > > With best wishes, > > > > Igor Tandetnik > > > > "For every complex problem, there is a solution that is simple, > > neat, > > > > and wrong." H.L. Mencken > > > > > I have a DLL which communicates via a socket to an embedded > > system. > > > > > This DLL > > > > > can now support 5 Control clients talking via 1 socket to the 1 > > > > > embedded > > > > > system. It supports the 5 clients by making a copy of the message > > to > > > > > shared > > > > > memory inside the DLL and then allowing the Control clients to > > read > > > > > these shared messages. > > > > > However if I exit the first Control client which is the one that > > > > > creates the > > > > > threads that handles the reading and writing of the socket, then > > all > > > > > communication stops for the other clients. That first one has the > > > > > Handle to the > > > > > Threads. > > > > > I could probably disallow the user from closing that first Client > > > > > however is it > > > > > possible to somehow disassociate the Threads from the process that > > > > > started them?
Tue, 22 Feb 2005 21:13:02 GMT

Page 1 of 1

[ 6 post ]