guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add current-suspendable-io-status parameter


From: Mark H Weaver
Subject: Re: [PATCH] Add current-suspendable-io-status parameter
Date: Mon, 13 May 2019 16:54:03 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Hi Nala,

Nala Ginrut <address@hidden> writes:

> Here's a patch to add current-suspendable-io-status:
> Its result is a pair: (finished-bytes . rest-bytes)
>
> This is useful for designing a proper scheduler algorithm for
> suspendable I/O operations.
> For example, the server-core based on delimited-continuation can
> compute a priority based on this status to decide how to schedule the
> suspended task.

I'm not inclined to apply this patch.  It would entail adding heap
allocation to a low-level I/O procedure that otherwise need not perform
any allocation.  Heap allocation happens both in 'cons' and in
'parameterize'.  We should try hard to avoid unnecessary complications
in these low-level routines.

I also have doubts about the utility of the information provided.
'start' seems completely irrelevant, since it merely indicates the
position within the read/write buffer.  It's easier to make a case that
'count' might be relevant, but it's not a reliable indicator of the
overall amount of pending I/O on that port.  With a few exceptions,
'count' is normally limited to the port buffer size, and does not
necessarily reflect the amount of I/O pending in the higher-level code.

If you'd like to use parameters to communicate pending I/O size to your
scheduler, I think it would be better to use 'parameterize' in your own
higher-level code, where you have the best knowledge of how much I/O
will need to be done.

If you still believe that your proposed patch is the best approach, and
that the benefit of your scheduling algorithm outweighs the cost of
adding these complications and heap allocations to our low-level I/O
procedures, can you help me to understand why?  Can you explain the
theory behind your scheduling algorithm?

     Regards,
       Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]