Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finish migrating System.Drawing.Common to ComWrappers #54884

Merged
merged 3 commits into from
Jul 6, 2021

Conversation

eerhardt
Copy link
Member

This resolves all ILLink warnings in System.Drawing.Common, making it work in a trimmed application.

cc @kant2002

This resolves all ILLink warnings in System.Drawing.Common, making it work in a trimmed application.
@ghost
Copy link

ghost commented Jun 29, 2021

Tagging subscribers to this area: @safern, @tarekgh
See info in area-owners.md if you want to be subscribed.

Issue Details

This resolves all ILLink warnings in System.Drawing.Common, making it work in a trimmed application.

cc @kant2002

Author: eerhardt
Assignees: -
Labels:

area-System.Drawing

Milestone: -

@eerhardt
Copy link
Member Author

Thanks for the feedback. I believe I have addressed it all with the latest changes. PTAL.

@eerhardt
Copy link
Member Author

eerhardt commented Jul 1, 2021

Libraries Test Run release coreclr Linux x64 Debug and Libraries Test Run release coreclr windows x86 Debug failures are all Http Functional tests, which are unrelated to this change.

Build tvOSSimulator x64 Release AllSubsets_Mono failed due to "AppleAppBuilderTask" task failed unexpectedly., which is also unrelated.

I believe this change is ready - any further feedback?

Interop.HRESULT hr = (Interop.HRESULT)WriteToStream(pstm, b, read, &written);
if (hr != Interop.HRESULT.S_OK)
{
return hr;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need to return the buffer in this case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been told by @GrabYourPitchforks that when an error occurs, it is usually best to not return buffers to the pool, since they could have corrupt/incomplete data in them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It depends on how common you expect the errors can be. We do not bother to return the buffer to the pool for very rare errors, like out-of-memory exceptions.

The error here may not be that rare and it is not perf critical path, so it would be reasonable to return the buffer in finally here. This is similar to Stream.CopyTo where we do return in finally as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note - the existing, "built-in COM" code doesn't return the buffer if an exception happens (which my understanding is that a COMException will occur since IStream defines Write as returning void, so the marshalling code will check the HR and throw):

byte[] buffer = ArrayPool<byte>.Shared.Rent(4096);
ulong remaining = cb;
ulong totalWritten = 0;
ulong totalRead = 0;
fixed (byte* b = buffer)
{
while (remaining > 0)
{
uint read = remaining < (ulong)buffer.Length ? (uint)remaining : (uint)buffer.Length;
Read(b, read, &read);
remaining -= read;
totalRead += read;
if (read == 0)
{
break;
}
uint written;
pstm.Write(b, read, &written);
totalWritten += written;
}
}
ArrayPool<byte>.Shared.Return(buffer);

@jkotas - do you think it is that common for an error to occur here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably not that common.

It is user supplied stream, so you can certainly constructs cases where the errors are common.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess my preference is to leave it then, since that is the existing behavior and we haven't heard complaints.

Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@safern safern left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@eerhardt eerhardt merged commit 890fde7 into dotnet:main Jul 6, 2021
@eerhardt eerhardt deleted the DrawingCOM branch July 6, 2021 19:20
kant2002 added a commit to kant2002/WinFormsComInterop that referenced this pull request Jul 9, 2021
wjk pushed a commit to SunburstApps/WinFormsComInterop that referenced this pull request Jul 9, 2021
akoeplinger added a commit to akoeplinger/runtime that referenced this pull request Jul 14, 2021
After dotnet#54884 these tests started failing on Mono on Windows, see dotnet#55655.
akoeplinger added a commit that referenced this pull request Jul 14, 2021
)

After #54884 these tests started failing on Mono on Windows, see #55655.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants