> Forking there is an exceptionally bad idea, since you're creating two copies
> of your mongrel, and copy-on-write semantics are effectively broken in
> ruby. So after you fork your mongrel, if the forked copy runs a GC it will
> force the OS to make a copy of it's memory, which is somewhere north of 50
> megs (probably a good bit more.)
> Threading inside of publish may not be the best strategy. One thing you
> could do is spin up two threads and call join on them. One thread can call
> publish and another can do any rendering/database/other work that needs to
> happen. Probably one of the simplest ways to mitigate the latency, however,
> is to move the call to an asynchronous XHR from the client, so that users
> don't notice it as much. However that isn't always possible. Hope that
> helps.
> On Tue, Jun 3, 2008 at 9:37 PM, Adam Greene <adam.gre...@gmail.com> wrote:
> > hey guys,
> > is there any reason why not to thread/fork within the Gateway/publish
> > method?
> > I'm using aSQS, and there is a noticeable latency, especially if the
> > retry logic is engaged. I'm wrapping my publish calls with a fork
> > (using spawn), but the fact that this wasn't already done makes me
> > wonder if I'm missing a 'gotcha'.
> > Is there any reason why it isn't threaded at the publish call? If
> > not, should I submit a patch?
> > Thanks folks,
> > Adam
> > ----
> > SweetSpot.dm -- Diabetes Wellness for the Family
> >http://www.SweetSpot.dm
> >http://blog.SweetSpot.dm
