gen_tcp:accept/{1,2} in passive mode?
Sean Hinde
Sean.Hinde@REDACTED
Thu Dec 14 18:23:42 CET 2000
Peter,
Any other top tips you might be able to share?
- Sean
> Sam,
>
> we have internally an inofficial FAQ which considers your problem:
>
> Q.11 : One process in my application is typically
> hanging in a call to
> gen_tcp:accept/1 waiting for a connection request. How
> do I perform
> code change for that process?
>
> A: Let the implementation be such that another process holds the
> listen socket and is linked to the process hanging in
> gen_tcp:accept/1. Specify an update code upgrade
> instruction with
> a very short timeout, which will cause the process to be
> killed almost immediately by the release handler, before the new
> version of the call-back module for the process is loaded. Then
> let the other process restart the process calling
> gen_tcp:accept/1.
>
> /Peter
>
> --------------------------------------------------------------
> -----------
>
> Peter Högfeldt e-mail : peter@REDACTED
> Open Telecom Platform Phone: : +46 (8) 727 57 58
> Ericsson Utvecklings AB Mobile : +46 070-519 57 51
> S-126 25 STOCKHOLM Fax: : +46 (8) 727 5775
> Office address: Armborstvägen 1, Älvsjö
>
> On Mon, 4 Dec 2000, Samuel Tardieu wrote:
>
> > I use gen_tcp:accept{1,2} a lot when doing servers, and I
> don't like the
> > fact that I cannot passively wait for connections, in a
> gen_server for example.
> > How do you deal with code change and a process being
> blocked in an accept
> > call? You can always use a timeout, but in this case you
> generate some
> > load when you exit the timeout just in case code needs to
> be changed.
> >
> > Wouldn't it be possible to set the accepting socket in
> passive mode, and
> > receive a message {Port, {accept, NewSocket, Origin}} for
> example when
> > a new connection arrives?
> >
> > Sam
> >
> >
>
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