[erlang-questions] Can gen_tcp/inets store connection-specific user state?

[Juan Jose Comellas]

The beauty of Erlang is precisely that you don't have to worry about this.
If you enable kernel polling (+K true) the VM will take care of using epoll,
kqueue, etc. (I'm not sure that IOCP is supported on Windows yet), and will
send the received data to the corresponding process, where you'll be able to
deal with it easily and without worrying about the underlying complexity of
low level I/O.

Why are you worried about having one Erlang process per connection? They are
very lightweight and that's where you're supposed to keep the state
associated to each connection if you want them to run in parallel.


On Thu, Jul 15, 2010 at 11:15 PM, Tony Arcieri <tony.arcieri@REDACTED>wrote:

> Many operating systems provide high-performance stateful I/O multiplexing
> APIs.  Some examples of these APIs include Linux's epoll, *BSD's kqueue,
> Solaris's event completion ports, and Windows I/O completion ports.
>
> A common characteristic of these APIs is the ability to include a pointer
> to
> a piece of user state.  This provides a simple way to look up the state
> necessary to dispatch an event.  A skillful user of these APIs will bundle
> all the state necessary to dispatch a request into a single pointer, and
> these APIs will keep track of that pointer, all the way down to the kernel
> level.
>
> As far as I can tell, gen_tcp/inets do not do this.  I am not seeing any
> APIs that will allow me to provide an Erlang term when I flip on active
> mode
> on a particular socket which will be delivered in the messages I receive
> from inets.
>
> Am I missing something?  Is there a way to do this?  If not, the recourses
> I
> have seem particularly disadvantageous compared to the underlying API
> carrying a single piece of state for me from end-to-end.  Either I can use
> a
> proxy process per connection, involving all the complexity of managing an
> external process in the API I expose to an end user, and requiring a
> process
> per connection where if gen_tcp/inets held onto the state for me I'd only
> require one, or having a single process which used a mapping data structure
> to go between the port the message originated from and the piece of user
> state I actually care about.  I find both of these solutions particularly
> suboptimal, especially considering that the kernel-level APIs are designed
> to round trip a particular piece of user state you care about end-to-end.
>
> The underlying functionality is there at the kernel level, but as far as I
> can tell Erlang does not expose it as a language.  Is there something I'm
> missing?
>
> --
> Tony Arcieri
> Medioh! A Kudelski Brand
>