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

setting the serialization for loopback and in-process sockets #361

Open
bangxiangyong opened this issue Sep 4, 2020 · 1 comment
Open

Comments

@bangxiangyong
Copy link

bangxiangyong commented Sep 4, 2020

in the run function of agent, the serializer for sockets has been hardcoded to be 'pickle', shouldn't this be set to the serializer of the individual agents, or the global serializer in osbrain.config?

what i find is that 'pickle' was still used to serialize the parameters of passed functions, although i specifically set to use other serializers.

therefore, changing the global osbrain.config['SERIALIZER'] doesn't change this behaviour either

snippet in agent.py

    @Pyro4.oneway
    def run(self):
        """
        Start the main loop.
        """
        # A loopback socket where, for example, timers are processed
        self.bind(
            'REP',
            alias='loopback',
            addr='loopback',
            handler=self._handle_loopback,
            transport='inproc',
            serializer='pickle',
        )

        # This in-process socket handles safe access to
        # memory from other threads (i.e. when using Pyro proxies).
        self.bind(
            'REP',
            alias='_loopback_safe',
            addr='_loopback_safe',
            handler=self._handle_loopback_safe,
            transport='inproc',
            serializer='pickle',
        )

i believe the fix should be to set serializer=self._serializer instead of serializer='pickle'

@Peque
Copy link
Member

Peque commented Sep 4, 2020

Thanks for reporting this issue! 😊

It sounds reasonable. Do you have a reproducible case that fails due to forcing pickle serialization in each of those cases? It would be great to have those in order to add tests when we make the required changes.

Pull requests are welcome, but always with the corresponding tests. 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development
Awaiting triage
Development

No branches or pull requests

2 participants