[Linux-streams] LiS-2.18.0: message loss problem

[eugenelisstreams]

Hello,

 

I have encountered the following message loss problem in LiS-2.18.0.

 

My application uses putpmsg() function to send messages.

 

LiS executes the following call sequence:

 

lis_strputpmsg() -> lis_putnext ==> lis_safe_putnext()-> lis_safe_do_putmsg()

In the lis_safe_do_putmsg() there is code fragment:
                            
    if ((err=lis_lockqf(q, f,l)) < 0)  <--- can fail due to EINTR
    {

        freemsg(mp) ;  /* busted */   <-- message dropped
        return(1) ;
    }

If application has periodical timer clicking, the
aforementioned lis_lockq() call can fail with the EINTR
if it was "lucky" to get hit by the timer while waiting on that lock.

 

The message is dropped silently in that case.
Without any notification sent to the originating putpmsg() in application.
[Since the lis_putenext() returns void to callers]

 

This is not good. I.e. it is bad.  Message loss. :(

I'm curious if other people experienced similar message loss scenarios.
Note, that lis_safe_do_putmsg(), via lis_putnext(), is called from
quite a number of other places.

 

BTW, that was not a problem in LiS-2.16.18 due to a different
lis_lockq() implementation.

I'm looking for an advice on how we can fix this problem.
(Perhaps Brian or Dan Gora can advice on this).

 

What I'm thinking about is if in the lis_safe_do_putmsg() function,
instead of dropping message when lis_lockq() fails, we could
place it into deferred queue?

 

In fact, in lis_safe_do_putmsg() function there are 2 calls
to the lis_defer_msg() function already.

 

Can we call lis_defer_msg() function when lis_lockq() fails there?

 

I'll appreciate all advices on the matter.

 

thanks,
--
Eugene

---

Try the New Netscape Mail Today!
Virtually Spam-Free | More Storage | Import Your Contact List
http://mail.netscape.com