On Wed, Apr 22, 2009 at 05:05:37PM +0200, Ryan Dahl <[email protected]> wrote:
> > I added a patch to libeio that make sit possible to override this:
> >
> > Is this a viable solution?
>
> Yes. thank you.
>
> Slightly off topic:
>
> Is there a reason not to include getaddrinfo directly in eio?
STACKSIZE!!111
> It seems like it'd be a common use for a thread pool. (Although having
> to increase the stacksize is one reason :))
Yeah, but not for the eio threadpool - it should be a separate threadpool.
Think about it that way: eio does async i/o, with vastly different latency
expectations than dns resolves. imagine you have 4 worker threads, and 16
hostname resolutions each taking 5 seconds, then your program couldn't do i/o
for over a minute.
the same applies to aio requests to different disks for example, resource
management is difficult... the point is, you are mixing vastly different
things in the same thread pool, which results in bad resource management.
thats why a) there is eio_group, and the IO::AIO feeder, so you can e..g
only ever use one thread slot for gethostbyname for example and b) why
there should be libetp, the e thread pool lib.
because the right way to approach this is to partition your thread pool
into multiple ones, or use multiple thread pools - one for gethostbyname,
and one for i/o stuff.
then different characteristics such as stacksize can be applied naturally
as well.
we are not there yet, of course, which is why the stacksize increase
solution exists....
> What about seek() ? pread/write are not always enough.
well, pread/pwrite obviously are always enough, as you can simply use your
own position indicator, and getting the current file position is hardly a
blocking operation.
any evidence (example of usefulness) to the contrary?
(in fact, I was very reluctant to event implment the offs < 0 special case
for read/write).
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
