On Sunday 19 February 2006 04:18 am, Christian Magnusson wrote:
> BTW: Does this timeout and ping packets take care of read/write commands
> that take long time to execute?
>
> For example, ow_2433.c:OW_w_mem() will call BUSLOCK()/BUSUNLOCK() three
> times during the write progress (+ BUSLOCK in bus_reset). This will
> probably delay the execution length since it could take several seconds
> between each BUSLOCK() if the 1-wire bus is busy with other commands.
>
> Just a quick thought about possible errors without reading the source with
> the latest changes.
>
> /Christian
>

I wrapped the current handler in owserver with another routine.

The wrapper saves the time, starts the real handler (in a separate thread) and 
loops every 0.1 seconds.

1. If the timer has been cleared, this signals the real handler is done, so 
the wrapper exits.
2.  If enough time has elapsed, the ping is sent, and the timer reset.
3. When the real handler sends data, it resets the timer, too.
4. The wrapper and real handler have a mutex to coordinate writing and timer 
manipulation.
5. The wrapping function lives longer, so it owns the stack space for the 
timer and mutex.

Have I missed anything?? The fall through if threading is not available or not 
enough resources is to call the handler in the same thread -- no pinging, but 
should function like the old days.

I worry a bit about the 0.1 seconds. There could theorectically be a lot of 
lingering threads around. My first design was to coordinate the threads 
directly, and use pthread_cancel to explicitly kill the pingger when the 
processing was done. It seems that pthread_cancel doesn't like nanosleep much 
(a lot of error 11 "Resource temporarily unavailable" when canceling.

Thinking about it, I can make the handling thread detatched (non-joinable) 
which is supposed to be cheaper. I also am using PTHREAD_MUTEX_INITIALIZER -- 
is that kosher with uClibc ?

Paul Alfille

P.S. Have you started some new threads of execution yet?


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Reply via email to