Prevent _s3_client from being serialized

[wouterzwerink]

Description of changes:

The latest version (0.10.0) of this library crashes when using S3 as data source with forking as spawn method of the DataLoader, since the S3 session object can not be pickled.

This PR fixes it by excluding the session from being serialized.

Issue #, if available:

Merge Checklist:

Put an x without space in the boxes that apply. If you are unsure about any checklist, please don't hesitate to ask. We are here to help! This is simply a reminder of what we are going to look for before merging your pull request.

General

• I have read the contributor guidelines
• This is a documentation change or typo fix. If so, skip the rest of this checklist.
• I certify that the changes I am introducing will be backward compatible, and I have discussed concerns about this, if any, with the MosaicML team.
• I have updated any necessary documentation, including README and API docs (if appropriate).

Tests

• I ran pre-commit on my change. (check out the pre-commit section of prerequisites)
• I have added tests that prove my fix is effective or that my feature works (if appropriate).
• I ran the tests locally to make sure it pass. (check out testing)
• I have added unit and/or integration tests as appropriate to ensure backward compatibility of the changes.

[snarayan21]

Hey @wouterzwerink, thanks for the contributions. Changes look fine to me and I'll kick off CI.

Related: In some cases in the past, we've seen StreamingDataset not work with multiprocessing via the fork() method and so we usually always recommend using spawn(). Is there a particular reason you're using fork()? And can you verify that multiprocess dataloading (nonzero number of workers) is working fine even with fork() for you?

@ethantang-db mind also taking a look?

[wouterzwerink]

Hey @wouterzwerink, thanks for the contributions. Changes look fine to me and I'll kick off CI.

Related: In some cases in the past, we've seen StreamingDataset not work with multiprocessing via the fork() method and so we usually always recommend using spawn(). Is there a particular reason you're using fork()? And can you verify that multiprocess dataloading (nonzero number of workers) is working fine even with fork() for you?

@ethantang-db mind also taking a look?

I'm using a private fork of VISSL, using DDP. It uses a forkserver by default (probably because it works nicely with SLURM?). Spawn should also work, but I had not tried it since forkserver has been working fine until 0.10.0.

I'll give 0 workers a try

[ethantang-db]

Looks good to me! Thanks for the update on this. Will approve after all test passes

[ethantang-db]

Also possibly in the future we should do this with all the other boto3 clients. My suspicion as to why fork doens't work well is because those clients probably establish some pybind backend that utilizes C which are not pickle-able

blocking until all tests passes

[snarayan21]

linting

[snarayan21]

lgtm