[plt-scheme] embedding: scheme_check_threads question

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

?