I think I should clarify. For something like read I imagine a portal call would happen and read would add the buffer/size/address to list of operations to be done in the service turf then sits in a loop yielding it’s thread time until the data is ready.
However if I’m doing this async what implementation is available for the service to notify the client that the data is ready? I can’t imagine the service would ever want to use it’s own thread to do work for the client. Some implementations I can think of are
1. Service thread uses a pointer to marks client data as available/%complete. Client sits in a loop checking to see if data is ready (and sleeping if nothing is ready)
2. Service creates a new thread which then uses a portal to call client async code
3. Service be able to interrupt client. Which appears to be a ‘knight move’ (changing the thread and turf) which you said is not possible on the mill.
I was wondering which would be optimal or possible on the mill. For sure the first is possible, the third I suspect not. As for the second option is spawning a thread everytime less than optimal? If the app/client is poorly behaved and never returns from the portal callback could this cause problems?
After writing this I suspect #1 is the safest most efficient method but a loop like this reminds me of a spinlock which probably isn’t expensive but isn’t my favorite method of notifying others of data
-
This reply was modified 4 years, 4 months ago by
CPUSpeedup.
-
This reply was modified 4 years, 4 months ago by