ESP8266 Community Forum

Ah crap, that's actually a known issue I've forgotten about. I'll look into it.

I see a comment in the cgiWebsocketBroadcast function that says it has buffer issues if used outside of the httpd send/receive context. I think the same is true for cgiWebsocketSend isn't it? I need to call that outside of the httpd send/receive context as well. I notice that the buffers are dynamically allocated anyway contrary to what the comments say about them being on the stack. If that's the case, couldn't httpdSend just allocate a buffer as needed?

dbetz wrote:I see a comment in the cgiWebsocketBroadcast function that says it has buffer issues if used outside of the httpd send/receive context. I think the same is true for cgiWebsocketSend isn't it? I need to call that outside of the httpd send/receive context as well. I notice that the buffers are dynamically allocated anyway contrary to what the comments say about them being on the stack. If that's the case, couldn't httpdSend just allocate a buffer as needed?

I guess it could, but I don't like allocating buffers like that on the fly, especially when FreeRTOS would also give you locking issues when doing that. Fyi I fixed the cgiWebsocketBroadcast function. Haven't looked at cgiWebsocketSend yet, it will indeed have similar problems when the websocket isn't the websocket that caused a cgi to call the cgiWebsocketSend function (that is: when you reply to a message from the client.) but I think a solution similar to the broadcast function could work.