Hi Keith,
I'm getting closer:
- For a reason I don't understand the posix_fallocate() does not work
correctly, I guess I miss something. The darwin.c method works better it
seems (at least the check returns less errors).
- As explained the main problem is coming from the fact I must
reassociate the port when the event reason is gone (pipe drained), i.e.:
- for read events I think the only location where I need to reassociate
is in serv.c as explained here above;
- for write events I'm lost in all the functions... I see a sockwant()
can possibly use 'w' (write) as argument in prot.c, but where do you
actually write ?
Can you help me here or do you have a picture/document explaining the
relationships between the functions or the like ?
I'm supposed to wait for the event source to be drained before
reassociating but, as a dirty workaround, I tried to reassociate
immediately after get_port() returns and I'm now left with only 3 errors.
Do you have any hints on these ?
x===============
ct/_ctcheck
.............E......EE..................................
cttestbinlogread: error (exit status 4)
start server port=59452 pid=777
>17 use test
<17 USING test
>17 put 0 0 120 4
>17 test
<17 INSERTED 1
>17 put 0 0 120 4
>17 tes1
<17 INSERTED 2
>17 watch test
<17 WATCHING 2
>17 reserve
<17 RESERVED 1 4
<17 test
>17 release 1 1 1
<17 RELEASED
>17 reserve
<17 RESERVED 2 4
<17 tes1
>17 delete 2
<17 DELETED
start server port=45731 pid=778
>19 watch test
<19 WATCHING 2
>19 reserve
<19 cttestbinlogread: SunOS.c:88 in socknext: port_get: Timer expired
response too big
cttestpause: error (exit status 4)
start server port=43651 pid=793
>24 put 0 0 0 1
>24 x
<24 INSERTED 1
>24 pause-tube default 1
<24 PAUSED
>24 reserve
<24 cttestpause: SunOS.c:88 in socknext: port_get: Timer expired
response too big
cttestreservewithtimeout2conn: error (exit status 4)
start server port=40832 pid=795
>25 watch foo
<25 WATCHING 2
>25 reserve-with-timeout 1
>26 watch foo
<26 WATCHING 2
<25 cttestreservewithtimeout2conn: SunOS.c:88 in socknext: port_get: Timer
expired
response too big
0 failures; 3 errors.
Makefile:72: recipe for target 'check' failed
gmake: *** [check] Error 1
x===============
TIA
On Monday, May 5, 2014 11:42:08 PM UTC+2, Keith Rarick wrote:
>
> The sock functions in beanstalkd presume that a file descriptor
> will remain associated with the requested events until it is
> explicitly requested to be changed or removed with another call
> to sockwant.
>
> The sockwant and socknext functions should satisfy that
> assumption. I don't know how to do it on Solaris, but for example
> BSD's kqueue has a flag EV_ONESHOT that lets the user control
> whether an association will persist.
>
> On Mon, May 5, 2014 at 2:03 AM, Pierre Dehaen <[email protected]<javascript:>>
> wrote:
> > Hi,
> >
> > Iin the output of make check I guess 'E' means error for one check and I
> > think I found at least one issue in my SunOS.c... According to the
> > port_associate() man page, after a port_get you must reassociate the
> object
> > to the port:
> > When an event for a PORT_SOURCE_FD object is retrieved, the object no
> longer
> > has an association with the port. The event can be processed without the
> > possibility that another thread can retrieve a subsequent event for the
> same
> > object. After processing of the file descriptor is completed, the
> > port_associate() function can be called to reassociate the object with
> the
> > port.
> >
> > I tried a quick hack in serv.c which seems the only place where
> socknext()
> > is used:
> > x================
> > *** ../beanstalkd-1.9.orig/serv.c Sun Apr 14 19:19:41 2013
> > --- serv.c Mon May 5 10:03:44 2014
> > ***************
> > *** 55,60 ****
> > --- 55,66 ----
> > if (rw) {
> > sock->f(sock->x, rw);
> > }
> > +
> > + r = sockwant(&s->sock, 'r');
> > + if (r == -1) {
> > + twarn("sockwant(reassociate)");
> > + exit(2);
> > + }
> > }
> > }
> > x================
> >
> > That did not solve the check issues (same result) but I think it is
> needed
> > anyway. I'm still checking the documentation but help would be
> welcome...
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "beanstalk-talk" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to [email protected] <javascript:>.
> > To post to this group, send email to
> > [email protected]<javascript:>.
>
> > Visit this group at http://groups.google.com/group/beanstalk-talk.
> > For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"beanstalk-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/beanstalk-talk.
For more options, visit https://groups.google.com/d/optout.
