<div dir="ltr"><div class="gmail_default" style="color:#3333ff">Thanks for your insights Andy.</div><div class="gmail_default" style="color:#3333ff"><br></div><div class="gmail_default" style="color:#3333ff">Unfortunately the platform is some RTOS running on tiny MCU, which is not powerful at all.</div><div class="gmail_default" style="color:#3333ff">The thread pool approach is not possible for me.</div><div class="gmail_default" style="color:#3333ff">For TLS, seems the solution is to speed it up by using other optimized libraries?</div><div class="gmail_default" style="color:#3333ff">For flash I/O, might need to sacrifice RAM by maintaining another copy of received data, and write it later to flash by different task?</div><div class="gmail_default" style="color:#3333ff"><br></div><div class="gmail_default" style="color:#3333ff">Have you helped with other guys on similar topics before, i.e., porting LWS on resource tight platforms? I do notice that there is esp32 support, but not many related sample apps I can find in this area.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 3, 2018 at 11:40 PM Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 04/10/18 14:14, Xi Chen wrote:<br>
> Hi, Andy<br>
> <br>
> I need help with dealing the following scenarios:<br>
<br>
What is the platform, something really weak?<br>
<br>
> [Server case - CPU]<br>
> - With mbedtls, the crypto job might be CPU-intensive, which will block <br>
> the LWS thread. This affects the concurrency capability supported by <br>
> LWS, right? Is it by design of LWS?<br>
<br>
Lws is nonblocking and singlethreaded, so yes it is by design.  You <br>
can't stop the event loop thread by spinning it in your code without <br>
stopping handling of events... this is a characteristic of all event <br>
loops not just lws.<br>
<br>
So you have to adapt your design if you won't block the event loop.<br>
<br>
> [Server case - I/O]<br>
> - Suppose server receives a POST request and need to save the data on <br>
> flash. I believe the flash write is blocking most likely, and is not <br>
> recommended to run in LWS callbacks. In this case, what is the <br>
> recommended way to deal with flash write in efficient way?<br>
<br>
... it depends on your platform resources and situation.<br>
<br>
If your platform is not very constrained, there's no good reason to use <br>
mbedtls when OpenSSL has many optimized implementations for common <br>
platforms.  OpenSSL is literally 20+x faster for common tls operations <br>
on x86_64.  (And OpenSSL maintainers are not high on NIH.)<br>
<br>
The write to serial flash situation you describe exists on the lws ESP32 <br>
stuff, when you upload the OTA firmware.  But because it's a modal <br>
firmware upgrade type situation, it's OK to block other things.<br>
<br>
To solve it, you have to move the slow activity to another thread or <br>
process.  That could take the form of buffering the data to be written <br>
in RAM and writing it separately (obviously the wisdom of that depends <br>
entirely on device resources...), or starting a thread when you see the <br>
requested task needs it and using rx flow control to modulate accepting <br>
new data against the progress of writing the last lot.  But I have not <br>
spent any time on http/2 rx flow control yet so this is only good for h1 <br>
as it stands.<br>
<br>
In the case the pattern is a client request triggers something that <br>
takes a long time to complete before generating output, if your platform <br>
is strong enough to support pthreads then look at threadpool:<br>
<br>
<a href="https://libwebsockets.org/git/libwebsockets/tree/lib/misc/threadpool" rel="noreferrer" target="_blank">https://libwebsockets.org/git/libwebsockets/tree/lib/misc/threadpool</a><br>
<br>
This lets a wsi defer answering on a connection until something it <br>
wanted to execute completed on a thread from a threadpool.  The event <br>
loop continues on as soon as the job is queued on the threadpool.  And <br>
the job can sync with the original wsi WRITEABLE callback when it is <br>
ready.  The advantage is lws absorbs ALL the thread synchronization <br>
stuff, you don't have to use any pthreads in your code.<br>
<br>
There's a minimal example for it here:<br>
<br>
<a href="https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/ws-server/minimal-ws-server-threadpool" rel="noreferrer" target="_blank">https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/ws-server/minimal-ws-server-threadpool</a><br>
<br>
Gitohashi (the git web interface those links use) runs everything via <br>
threadpool, because stuff like the blame view can be slow to generate. <br>
By using threadpool a slow job doesn't cause any delay for other clients <br>
(until the pool of threads is wholly occupied).  And it can be running n <br>
slow jobs on n cores that way, giving a speedup overall.<br>
<br>
-Andy<br>
<br>
> Thanks<br>
> -Xi<br>
> <br>
> <br>
> _______________________________________________<br>
> Libwebsockets mailing list<br>
> <a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a><br>
> <a href="https://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">https://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
> <br>
</blockquote></div>