gen_tcp:controlling_process

Sean Hinde <>
Fri Feb 28 12:53:56 CET 2003


> Jay,
>     gen_tcp accepts the option {active, true}. The purpose of this
> option is to allow the receipt of incoming tcp packets as 
> messages to be
> delivered to a specific processes mailbox. One would need to use the
> controlling_process function in order to direct incoming packets to an
> alternate mailbox. If you look at the code for gen_tcp it seems the
> obvious race conditions have been handled but I would use it 
> with care.
> 
> Cheers,
> Martin
> 
> On Thu, 2003-02-27 at 01:33, Jay Nelson wrote:
> > When is gen_tcp:controlling_process necessary?
> > 
> > I have a function that is blocking on an accept call
> > waiting for a Socket connection.  When it gets one,
> > it spawns a new process, passes the Socket, and
> > then starts accept again.  The new process is able
> > to read the Socket without having been given access
> > by gen_tcp:controlling_process.  Is that normal?

As Martin says "use with care" it is worth pointing out another way of doing
this:

Have a process which owns the listening socket. This will spawn a socket
process which will block in accept until a client arrives - at which time it
messages back to the listening process to tell it to spawn a new
socket/accepting process.

This model is widely used but for a very nice example take a look at joe's
recent web_server tutorial. http://www.sics.se/~joe

Sean









> > 
> > I am running on RedHat 7.3 x86 architecture.
> > 
> > jay
> 
> 



 NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.




More information about the erlang-questions mailing list