← index #7878Issue #3208
Off-topic · high · value 0.376
QUERY · ISSUE

ussl.wrap_socket: option for pre-allocated buffer

openby fragmuffinopened 2021-10-04updated 2022-05-13

Problem Description

Wrapping a socket requires ~16kB of RAM.
When memory is heavily fragmented, wrapping a socket will fail:

>>> secure_socket = ussl.wrap_socket(...)
MemoryError: memory allocation failed, allocating 16725 bytes

Proposed Solution

Instead, it could be possible to pre-allocate the memory (early in runtime), and share that with the wrapped socket... for example:

buf = bytearray(16725)
secure_socket = ussl.wrap_socket(..., buf=buf)
CANDIDATE · ISSUE

close method of SSL-wrapped sockets is not idempotent

closedby alex-robbinsopened 2017-07-12updated 2017-07-19
bug

On MicroPython (as well as CPython), file objects and sockets can both have their close methods called multiple times (calls after the first have no effect; the operation is idempotent). On MicroPython (but not CPython), this is not the case for the objects returned by ussl.wrap_socket. With these objects, a second call to close causes a crash (a segfault on Unix and a reset on the ESP8266).

A closed SSL socket still has normal-ish (non-crashing) behavior with other functions, so I guess nothing's being garbage collected or deallocated or anything.

I think the behavior is undesirable because, besides being unexpected and incompatible with CPython, it also makes error handling for user-defined classes tricky in the event that the socket in question may or may not have already been closed. There is also no way to test a socket to see if it has been closed.

Keyboard

j / / n
next pair
k / / p
previous pair
1 / / h
show query pane
2 / / l
show candidate pane
c
copy suggested comment
r
toggle reasoning
g i
go to index
?
show this help
esc
close overlays

press ? or esc to close

copied