Pools, pipes and filters or Stream Algebra

Shawn Pearce spearce@REDACTED
Mon Mar 24 21:47:21 CET 2003


I've thought that there are two things sort-of missing from the
gen_* modules which would be nice to have:

1) Local version of pg, dispatching requests onto worker threads for
   long running operations, etc.  Sort of a mini-mdisp or something.
   These are pretty easy to write in Erlang, but still somewhat hard.
   Would need to be able to limit the maximum number of worker
   processes, etc.

   I have a simple version of this type of service where there is a
   maximum number of workers to run and requests are queued up when
   this number is exceeded.  Essentially an 'async' background process.

2) gen_tcp_server, a gen_server based generic TCP server to handle any
   protocol by handing the protocol to the callback module.  Ideally
   this would also support the ssl application and support either
   plaintext or ssl sockets, but only require the callback module to
   implement one set of calls:

init(Sock,Args) ->
	init the callback protocol handler with the newly accepted socket
	and the handler's arguments.
handle_call(Req, From, State) -> standard gen_server handle_call/3.
handle_cast(Req, State) -> standard gen_server handle_cast/2.
handle_info(Req, State) -> standard gen_server handle_info/2.
handle_socket({data, Sock, Data}, State) ->;
handle_socket({closed, Sock} State) ->;
handle_socket({error, Sock, Data}, State) ->;
   	converting tcp, tcp_closed, tcp_error into data, closed, error,
	and ssl, ssl_closed, ssl_error into data, closed error.  Thus
	one service module can handle either SSL or plaintext.

   or some such thing.

   Again, it should implement process controls, registration, proper
   socket handling, perhaps an ets table of all current connections,
   lookup of service process by connection info, admin tools to kill
   connections individually, etc.

Even if either of both of these became commonly used user contribs
that would be good.  :)

I can provide my current modules that I use for the above two cases,
but I'm sure the Erlang masters have better ones to start from.


Vlad Dumitrescu <vlad_dumitrescu@REDACTED> wrote:
> Hi,
> 
> It occured to me that in order to provide a multi-process implementation for
> some functionality, so that this feature is transparent to the clients, we
> would need somehing like process groups. Using it, one could for example
> easily and dynamically extend Joe's mini-web server so that it can handle
> FTP requests, or anything asking for a file.
> 
> However, the pg module is still experimental. Are there plans to develop it
> further?
> 
> regards,
> Vlad

-- 
Shawn.

  tax office, n.:
  	Den of inequity.



More information about the erlang-questions mailing list