> On 1 Dec 2022, at 12:10, Andrew Cooper wrote:
>
> On 01/12/2022 11:20, Christian Lindig wrote:
>>
>>> On 30 Nov 2022, at 16:54, Andrew Cooper wrote:
>>>
>>> Generally speaking, the event channel local/remote port is fixed for the
>>> lifetime of the associated domain object. The exceptio
> On 1 Dec 2022, at 12:10, Andrew Cooper wrote:
>
> I can keep the being/end if you'd prefer.
>
> Looking at the end result, it would actually shrink the patch, so is
> probably worth doing anyway for clarity. The net result is:
I think keeping the begin/end is a good idea - as it keeps the
On 01/12/2022 11:20, Christian Lindig wrote:
>
>> On 30 Nov 2022, at 16:54, Andrew Cooper wrote:
>>
>> Generally speaking, the event channel local/remote port is fixed for the
>> lifetime of the associated domain object. The exception to this is a
>> secondary XS_INTRODUCE (defined to re-bind to
> On 30 Nov 2022, at 16:54, Andrew Cooper wrote:
>
> Generally speaking, the event channel local/remote port is fixed for the
> lifetime of the associated domain object. The exception to this is a
> secondary XS_INTRODUCE (defined to re-bind to a new event channel) which pokes
> around at the
> On 30 Nov 2022, at 16:54, Andrew Cooper wrote:
>
> Generally speaking, the event channel local/remote port is fixed for the
> lifetime of the associated domain object. The exception to this is a
> secondary XS_INTRODUCE (defined to re-bind to a new event channel) which pokes
> around at the
Generally speaking, the event channel local/remote port is fixed for the
lifetime of the associated domain object. The exception to this is a
secondary XS_INTRODUCE (defined to re-bind to a new event channel) which pokes
around at the domain object's internal state.
We need to refactor the evtchn
