|Keep It Simple, Stupid|
Re: Keeping an INET socket inside a shared objectby Superfox il Volpone (Sexton)
|on Jan 18, 2014 at 16:15 UTC||Need Help??|
Thank you for replies.
oh, I did not expect such situation when I started to code my project. So basically I have a bunch of workers that should offload the work on different machines, a master that schedule the work to the remote workers, and a set of users that send work to be done and query the current status. The communication is intrinsically non deterministic, because workers can report their status, or the raise of issues, to the master at different times, while the master can demand different services to workers.
In the master, I thought to set a different handler to each worker or user. As the handlers should cooperate each other and keep a consistent view in every moment, I did immediately model them as shared objects. Eventually, since each handler should "own" its connection socket, it came up pretty natural the willing to associate the socket with its handler. But the object is shared for its own nature, while the socket is not, therefore my struggle.
The second motivation is, I imagine, conceptual. Because if TCP is sequentially bidirectional (that`s new to me), it is conceptually bidirectional, i.e. there are two different untied streams to read/write, which allow two different flows to take place...
I did a step ahead, being able to share a socket among certain threads. I guess there was a problem of scope, the socket was destroyed in the ctor itself. This is my updated code:
I understand that Perl wants to emulate the threads as heavy processes. When we create a thread, I guess it inherits all the file handles of the creator. If we would create a socket in a child, then neither the father nor its brothers would be aware, wouldn`t be? I wonder what were the initial motivations to introduce a such exotic thread model at the first place.
Again, I am getting the feeling I am trying to bend the language for something it was not supposed to perform... :oO