[plt-scheme] embedding: scheme_check_threads question

On Thu, 2009-04-23 at 10:08 -0600, Matthew Flatt wrote:
> At Thu, 23 Apr 2009 16:47:32 +0100, Dave Griffiths wrote:
> > On Wed, 2009-04-22 at 10:59 -0600, Matthew Flatt wrote:
> > > The scheme_check_threads() function performs a single round of thread
> > > swaps, and "round" depends on the structure of thread grups. If you
> > > have 100 active threads all in the same thread group, then it should
> > > let each of them run. If you have 100 threads in a nested thread group,
> > > though, it may take 100 calls for each thread within the group to get a
> > > chance to run. I think.
> > > 
> > > How many other threads are there? do you create any thread groups?
> > 
> > In this case not that many (I'm not entirely sure), but they are needing
> > frequent updates as some of them are polling network sockets for stuff.
> > 
> > But in the general case, if the frequency/quantity of the
> > scheme_check_threads calls should dependant on the number of threads, is
> > there a way to find out and scale it appropriately?
> 
> If there are no thread groups involved, then it shouldn't really depend
> on the number of threads.
> 
> The fact that network sockets are involved may be more relevant.
> Calling scheme_check_threads() 100 times shouldn't take much time, but
> it could be at the scale where 100 calls takes long enough that data
> becomes available, while 1 time is too fast. That could streamline
> overall scheduling if the time between the next 1 (or 100) calls to
> scheme_check_threads() is much longer than the time between socket
> events.
> 
> I have seen dramatic differences in times for socket-based programs
> depending on exactly how the sockets are polled. As far as I can tell,
> the MzScheme scheduler and the OS scheduler can interact badly, since
> neither is particularly aware of the other. The problem may be
> elsewhere in this case, but that's worth keeping in mind.
> 
> So, what are the time scales involved? Can you measure
> 
>  * how frequently scheme_check_threads() is called,
> 
>  * how long each call to scheme_check_threads() takes, and
> 
>  * the time between network events

I've yet to time things accurately, but I replaced the
scheme_check_threads loop with usleep(1000), and I get problems again.

Adding (sleep 0.01) to the end of my scheme update loop works well
though (which I guess effectively does the same thing as calling
scheme_check_threads).

cheers,

dave