beepcore-c-users — Discussion list for developers using beepcore-c library

Re: [Beepcore-c-users] Mysterious socket error

[David C N. <dc...@ad...>]

On Fri, 9 Jan 2004, Lei Zhang wrote:
> I've noticed this too.  I changed the threading model to one thread per 
> channel a couple of months ago, that probably explains why I'm not 
> having the problem that's bothering David.

As far as I can see, this is NOT what thread_per_channel does -- without 
it, there would be only one thread allocated total, as opposed to one per 
channel.  Although pfa() does seem to get called multiple times 
concurrently, evidently meaning there are multiple threads.


-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------

Re: [Beepcore-c-users] race condition

[Lei Z. <lz...@ju...>]

bummer, scratch that.  It's my bad, I modified 
waitfor_chan_stat_quiescent() to debug another problem... sorry about 
the fuss.

Lei Zhang wrote:

> Just tripped over another beepcore-c problem: race condition at 
> session shutdown time.  I'm gonna use null-profile.c to explain the 
> problem:
>
> In null-profile.c:
> pro_frame_available ()
> {
> 1.    f = bpc_query_frame(...)
>
> 2.    /* do fancy processing */
>
> 3.    bpc_frame_destroy();
> }
>
> In 2. a RPY can be sent to acknowlege a MSG; now the channel 0 thread 
> takes over and destroys the null-profile channel instance (because the 
> channel is considered QUIESCENT); now back to the above 3, bummer!! 
> core dump on GET_WRAPPER(inst->conn) then grabbing wrap->core_lock!
>
> I'm now just working around this by doing bpc_frame_destroy() before 
> sending RPY.  Any better/real fix?
>

[Beepcore-c-users] race condition

[Lei Z. <lz...@ju...>]

Just tripped over another beepcore-c problem: race condition at session 
shutdown time.  I'm gonna use null-profile.c to explain the problem:

In null-profile.c:
pro_frame_available ()
{
1.    f = bpc_query_frame(...)

2.    /* do fancy processing */

3.    bpc_frame_destroy();
}

In 2. a RPY can be sent to acknowlege a MSG; now the channel 0 thread 
takes over and destroys the null-profile channel instance (because the 
channel is considered QUIESCENT); now back to the above 3, bummer!! core 
dump on GET_WRAPPER(inst->conn) then grabbing wrap->core_lock!

I'm now just working around this by doing bpc_frame_destroy() before 
sending RPY.  Any better/real fix?

Thanks,
Lei

William J. Mills wrote:

>Fair enough. :)
>

Re: [Beepcore-c-users] Mysterious socket error

[William J. M. <wm...@es...>]

Fair enough. :)


On Fri, Jan 09, 2004 at 03:22:50PM -0800, Lei Zhang wrote:
> William J. Mills wrote:
> 
> >David,
> >
> >Is the threading model in the wrapper broken to the point where 
> >two pfa() get called on the same channel in different threads?
> >
> I've noticed this too.  I changed the threading model to one thread per 
> channel a couple of months ago, that probably explains why I'm not 
> having the problem that's bothering David.
> 
> >
> >Why use pfa instead of pma?
> >
> I'm using pfa() for one of my profiles as well, because messages on that 
> channel easily goes way over window_size.  The 'How to write profile' 
> documentation suggests to use pfa() in this situation after all... so I 
> give up figuring out how beepcore-c's window resizing mechanism works...
> 
> Lei
> 
> 

Re: [Beepcore-c-users] Mysterious socket error

[Lei Z. <lz...@ju...>]

William J. Mills wrote:

>David,
>
>Is the threading model in the wrapper broken to the point where 
>two pfa() get called on the same channel in different threads?
>
I've noticed this too.  I changed the threading model to one thread per 
channel a couple of months ago, that probably explains why I'm not 
having the problem that's bothering David.

>
>Why use pfa instead of pma?
>
I'm using pfa() for one of my profiles as well, because messages on that 
channel easily goes way over window_size.  The 'How to write profile' 
documentation suggests to use pfa() in this situation after all... so I 
give up figuring out how beepcore-c's window resizing mechanism works...

Lei

Re: [Beepcore-c-users] Mysterious socket error

[William J. M. <wm...@es...>]

David,

Is the threading model in the wrapper broken to the point where 
two pfa() get called on the same channel in different threads?
That would be bad.

Yes, there should be header information in the frame telling you 
exactly what is going on, and they get delivered in sequence.  The
specifics are in the rfc, theres a single char to indicate continuation.

Why use pfa instead of pma?

-bill


I beielev you get the header infor for the frame as well?
On Fri, Jan 09, 2004 at 05:55:34PM -0500, David C Niemi wrote:
> 
> Thanks for the info.
> 
> I think I have figured out what the problem is, though it is not entirely 
> clear to me how to solve it.  Here's what I think is happening:
> 
> All the action is in pro_frame_available() in my profile, which is dealing
> with frames, not whole messages.  Due to the fragmentation bug in
> beepcore-c, even my small messages often get broken into several small
> frames during transmission (usually a few hundred bytes).
> 
> To deal with this, I have a linked list tracking the status of each 
> message by number as it comes in.  But there is a fair amount of 
> processing involved in locking the list and adding an entry in it, so I am 
> not doing it immediately upon receiving the first frame in the message.  
> Instead, I have been doing it towards the end of pro_frame_available when 
> I have determined that this is the first frame but not the last frame 
> (although come to think of it I know this earlier on).
> 
> So anyway, what happens is that the first frame comes in, pfa() thinks 
> about it a while, and then the second frame for the message comes in and 
> pfa() gets called again.  Both of these instances of pfa() think that it's 
> a new message, and it's a race condition as to which one records it first, 
> causing great confusion.  It's possible the dropped sessions are due to 
> this bug as well.
> 
> To cure this, I really need to lock the linked list before I even pick up 
> a frame, to prevent another instance of pfa() from sneaking in with a 
> subsequent frame in the same message oblivious to the fact that the first 
> frame has already been received.  And if it is a new but not complete 
> frame, I need to create the entry for it then.  If this isn't a new one, 
> it'll have to wait for a lock, which is good, because then by the time it 
> can get the lock the new entry will be in place for it to find.  Does this 
> make sense?
> 
> Is there anything about a frame that indicates intrinsically if it is the 
> first frame in a message?
> 
> DCN
> 
> On Thu, 8 Jan 2004, Lei Zhang wrote:
> > Looks like your TCP connection is broken.  revents=0x19/0x19 means 
> > POLLIN | POLLERR | POLLHUP.
> > 
> > I've been fiddling with beepcore-c for a few months, haven't noticed 
> > frames getting lost - can you tell how to trigger that kind of error?
> > 
> > Thanks,
> > Lei
> > 
> >  David C Niemi wrote:
> > 
> > >I am again working on my application built on beepcore-c (under Linux).  
> > >I occasionally have BEEP sessions (or at least channels) just drop for no
> > >apparent reason.  The log file shows this:
> > >
> > >01/08 10:33:00 beepd-re 2.core start logging
> > >01/08 10:33:00 beepd-re 2.wrap loaded profile for http://www.adeptech.com/beryllium/BERYL/RECEIVE
> > >01/08 10:33:00 beepd-re 1.wrap duplicate library libberyl.so, continuing...
> > >01/08 10:33:00 beepd-re 2.wrap loaded profile for http://www.adeptech.com/beryllium/BERYL/SEND
> > >01/08 10:33:00 beepd-re 2.wrap listening on 5 (backlog 128)
> > >01/08 10:33:32 beepd-re 0.wrap wrapper created: 6
> > >01/08 10:33:32 beepd-re 1.wrap wrote 218 octets
> > >01/08 10:33:32 beepd-re 1.wrap wrote 15 octets
> > >01/08 10:33:33 beepd-re 1.wrap read 67 octets
> > >[...]
> > >01/08 10:36:04 beepd-re 1.wrap read 18 octets
> > >01/08 10:36:04 beepd-re 1.wrap wrote 395 octets
> > >01/08 10:36:04 beepd-re 1.wrap wrote 1913 octets
> > >01/08 10:36:04 beepd-re 1.wrap wrote 353 octets
> > >[normal so far]
> > >01/08 10:36:04 beepd-re 2.wrap id=0 fd=6 revents=0x19/0x19
> > >01/08 10:36:04 beepd-re 0.wrap socket error: 6
> > >01/08 10:36:04 beepd-re 0.wrap stopping iostate: 6
> > >01/08 10:36:04 beepd-re 0.wrap deleting iostate: 6
> > >
> > >What is a socket error, and how can I prevent it or recover from it?
> > >
> > >I am also seeing problems with frames getting lost, I'm not quite sure 
> > >why yet but perhaps they are related.  The traffic is over a lightly 
> > >loaded 100TX network.
> > >
> > >>From the peer's perspective, I see messages like this:
> > >12/30 10:49:16 runberyl 2.wrap id=0 fd=5 revents=0x11/0x1
> > >12/30 10:49:16 runberyl 0.wrap socket error: 5
> > >12/30 10:49:16 runberyl 0.wrap stopping iostate: 5
> > >12/30 10:49:16 runberyl 0.wrap deleting iostate: 5
> > >12/30 10:49:29 runberyl 2.core start logging
> > >12/30 10:49:29 runberyl 0.wrap wrapper created: 5
> > >12/30 10:49:29 runberyl 1.wrap wrote 150 octets
> > >[...]
> > >12/30 10:49:29 runberyl 1.wrap wrote 15 octets
> > >12/30 10:49:29 runberyl 1.wrap read 16 octets
> > >12/30 10:49:50 runberyl 0.wrap wrapper destroyed: 5
> > >12/30 10:49:50 runberyl 0.wrap stopping iostate: 5
> > >12/30 10:49:50 runberyl 0.wrap deleting iostate: 5
> > >12/30 10:49:50 runberyl 2.core done logging
> > >
> > >
> > >
> > >
> > >-------------------------------------------------------
> > >-- David C. Niemi           Adeptech Systems, Inc.   --
> > >-- Reston, Virginia, USA    http://www.adeptech.com/ --
> > >-------------------------------------------------------
> > >
> > >
> > >
> > >-------------------------------------------------------
> > >This SF.net email is sponsored by: Perforce Software.
> > >Perforce is the Fast Software Configuration Management System offering
> > >advanced branching capabilities and atomic changes on 50+ platforms.
> > >Free Eval! http://www.perforce.com/perforce/loadprog.html
> > >_______________________________________________
> > >Beepcore-c-users mailing list
> > >Bee...@li...
> > >https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
> > >
> > >
> > 
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Perforce Software.
> > Perforce is the Fast Software Configuration Management System offering
> > advanced branching capabilities and atomic changes on 50+ platforms.
> > Free Eval! http://www.perforce.com/perforce/loadprog.html
> > _______________________________________________
> > Beepcore-c-users mailing list
> > Bee...@li...
> > https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
> > 
> 
> -- 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

Re: [Beepcore-c-users] Mysterious socket error

[David C N. <dc...@ad...>]

Thanks for the info.

I think I have figured out what the problem is, though it is not entirely 
clear to me how to solve it.  Here's what I think is happening:

All the action is in pro_frame_available() in my profile, which is dealing
with frames, not whole messages.  Due to the fragmentation bug in
beepcore-c, even my small messages often get broken into several small
frames during transmission (usually a few hundred bytes).

To deal with this, I have a linked list tracking the status of each 
message by number as it comes in.  But there is a fair amount of 
processing involved in locking the list and adding an entry in it, so I am 
not doing it immediately upon receiving the first frame in the message.  
Instead, I have been doing it towards the end of pro_frame_available when 
I have determined that this is the first frame but not the last frame 
(although come to think of it I know this earlier on).

So anyway, what happens is that the first frame comes in, pfa() thinks 
about it a while, and then the second frame for the message comes in and 
pfa() gets called again.  Both of these instances of pfa() think that it's 
a new message, and it's a race condition as to which one records it first, 
causing great confusion.  It's possible the dropped sessions are due to 
this bug as well.

To cure this, I really need to lock the linked list before I even pick up 
a frame, to prevent another instance of pfa() from sneaking in with a 
subsequent frame in the same message oblivious to the fact that the first 
frame has already been received.  And if it is a new but not complete 
frame, I need to create the entry for it then.  If this isn't a new one, 
it'll have to wait for a lock, which is good, because then by the time it 
can get the lock the new entry will be in place for it to find.  Does this 
make sense?

Is there anything about a frame that indicates intrinsically if it is the 
first frame in a message?

DCN

On Thu, 8 Jan 2004, Lei Zhang wrote:
> Looks like your TCP connection is broken.  revents=0x19/0x19 means 
> POLLIN | POLLERR | POLLHUP.
> 
> I've been fiddling with beepcore-c for a few months, haven't noticed 
> frames getting lost - can you tell how to trigger that kind of error?
> 
> Thanks,
> Lei
> 
>  David C Niemi wrote:
> 
> >I am again working on my application built on beepcore-c (under Linux).  
> >I occasionally have BEEP sessions (or at least channels) just drop for no
> >apparent reason.  The log file shows this:
> >
> >01/08 10:33:00 beepd-re 2.core start logging
> >01/08 10:33:00 beepd-re 2.wrap loaded profile for http://www.adeptech.com/beryllium/BERYL/RECEIVE
> >01/08 10:33:00 beepd-re 1.wrap duplicate library libberyl.so, continuing...
> >01/08 10:33:00 beepd-re 2.wrap loaded profile for http://www.adeptech.com/beryllium/BERYL/SEND
> >01/08 10:33:00 beepd-re 2.wrap listening on 5 (backlog 128)
> >01/08 10:33:32 beepd-re 0.wrap wrapper created: 6
> >01/08 10:33:32 beepd-re 1.wrap wrote 218 octets
> >01/08 10:33:32 beepd-re 1.wrap wrote 15 octets
> >01/08 10:33:33 beepd-re 1.wrap read 67 octets
> >[...]
> >01/08 10:36:04 beepd-re 1.wrap read 18 octets
> >01/08 10:36:04 beepd-re 1.wrap wrote 395 octets
> >01/08 10:36:04 beepd-re 1.wrap wrote 1913 octets
> >01/08 10:36:04 beepd-re 1.wrap wrote 353 octets
> >[normal so far]
> >01/08 10:36:04 beepd-re 2.wrap id=0 fd=6 revents=0x19/0x19
> >01/08 10:36:04 beepd-re 0.wrap socket error: 6
> >01/08 10:36:04 beepd-re 0.wrap stopping iostate: 6
> >01/08 10:36:04 beepd-re 0.wrap deleting iostate: 6
> >
> >What is a socket error, and how can I prevent it or recover from it?
> >
> >I am also seeing problems with frames getting lost, I'm not quite sure 
> >why yet but perhaps they are related.  The traffic is over a lightly 
> >loaded 100TX network.
> >
> >>From the peer's perspective, I see messages like this:
> >12/30 10:49:16 runberyl 2.wrap id=0 fd=5 revents=0x11/0x1
> >12/30 10:49:16 runberyl 0.wrap socket error: 5
> >12/30 10:49:16 runberyl 0.wrap stopping iostate: 5
> >12/30 10:49:16 runberyl 0.wrap deleting iostate: 5
> >12/30 10:49:29 runberyl 2.core start logging
> >12/30 10:49:29 runberyl 0.wrap wrapper created: 5
> >12/30 10:49:29 runberyl 1.wrap wrote 150 octets
> >[...]
> >12/30 10:49:29 runberyl 1.wrap wrote 15 octets
> >12/30 10:49:29 runberyl 1.wrap read 16 octets
> >12/30 10:49:50 runberyl 0.wrap wrapper destroyed: 5
> >12/30 10:49:50 runberyl 0.wrap stopping iostate: 5
> >12/30 10:49:50 runberyl 0.wrap deleting iostate: 5
> >12/30 10:49:50 runberyl 2.core done logging
> >
> >
> >
> >
> >-------------------------------------------------------
> >-- David C. Niemi           Adeptech Systems, Inc.   --
> >-- Reston, Virginia, USA    http://www.adeptech.com/ --
> >-------------------------------------------------------
> >
> >
> >
> >-------------------------------------------------------
> >This SF.net email is sponsored by: Perforce Software.
> >Perforce is the Fast Software Configuration Management System offering
> >advanced branching capabilities and atomic changes on 50+ platforms.
> >Free Eval! http://www.perforce.com/perforce/loadprog.html
> >_______________________________________________
> >Beepcore-c-users mailing list
> >Bee...@li...
> >https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
> >
> >
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
> 

-- 
-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------

Re: [Beepcore-c-users] Os X

[Torsten R. <tor...@hi...>]

On 8.1.2004, at 21:38, William J. Mills wrote:
> Should not be too hard to add OS X as a configure platform.  Did you
> want to take a shot at it?
I'd gladly help, but

>  Have you ever played with autoconf?

No. I type ./configure on a regular basis, but am aware that I really 
don't have a glue what's going on.

> I can give you some help maybe, but I don't have an OS X platform to 
> work with.

If you send me a diff, or check something in that "should" work, I'll 
try it out.

I wouldn't even know what symbols you can check for. the triple is 
powerpc-apple-darwin7.2.0 .

Well, if you're ready to go for it, let's tackle it offline,

Torsten

Re: [Beepcore-c-users] Os X

[William J. M. <wm...@es...>]

Way cool! 

Should not be too hard to add OS X as a configure platform.  Did you
want to take a shot at it?  Have you ever played with autoconf?

I can give you some help maybe, but I don't have an OS X platform to
work with.

Regards,

-bill


On Thu, Jan 08, 2004 at 04:39:14PM +0200, Torsten Rueger wrote:
> Moi,
> 
> awfully quit here, is there still anyone around ? Would love to hear 
> some good news. I've spend the last month implementing one of our 
> protocols using Beepy, pythons beep implementation, and that went well. 
> Now for a c  server.
> 
> I got the cvs version to compile on Os X 10.3.2 with only minor tweaks:
> 
> I removed the cyrus-profiles compilation, it was referring to sasl.h, 
> where is that ?
> 
> I hardcoded FREEBSD as threading model like
> Index: threaded_os/utility/semutex.h
> ===================================================================
> RCS file: /cvsroot/beepcore-c/beepcore-c/threaded_os/utility/semutex.h,v
> retrieving revision 1.12
> diff -r1.12 semutex.h
> 17a18
>  > #define FREEBSD 1
> 
> Not pretty, but worked. Is there a way to pass that as configure option 
> or for the configure to set that correctly ?
> 
> Lastly, it wasn't finding struct iovec correctly, so I did
> Index: base/generic/CBEEP.h
> ===================================================================
> RCS file: /cvsroot/beepcore-c/beepcore-c/base/generic/CBEEP.h,v
> retrieving revision 1.2
> diff -r1.2 CBEEP.h
> 28a29,30
>  > #include <sys/types.h>
>  > #include <unistd.h>
> 
> Best,
> 
> 	Torsten

Re: [Beepcore-c-users] Mysterious socket error

[Lei Z. <lz...@ju...>]

Looks like your TCP connection is broken.  revents=0x19/0x19 means 
POLLIN | POLLERR | POLLHUP.

I've been fiddling with beepcore-c for a few months, haven't noticed 
frames getting lost - can you tell how to trigger that kind of error?

Thanks,
Lei

 David C Niemi wrote:

>I am again working on my application built on beepcore-c (under Linux).  
>I occasionally have BEEP sessions (or at least channels) just drop for no
>apparent reason.  The log file shows this:
>
>01/08 10:33:00 beepd-re 2.core start logging
>01/08 10:33:00 beepd-re 2.wrap loaded profile for http://www.adeptech.com/beryllium/BERYL/RECEIVE
>01/08 10:33:00 beepd-re 1.wrap duplicate library libberyl.so, continuing...
>01/08 10:33:00 beepd-re 2.wrap loaded profile for http://www.adeptech.com/beryllium/BERYL/SEND
>01/08 10:33:00 beepd-re 2.wrap listening on 5 (backlog 128)
>01/08 10:33:32 beepd-re 0.wrap wrapper created: 6
>01/08 10:33:32 beepd-re 1.wrap wrote 218 octets
>01/08 10:33:32 beepd-re 1.wrap wrote 15 octets
>01/08 10:33:33 beepd-re 1.wrap read 67 octets
>[...]
>01/08 10:36:04 beepd-re 1.wrap read 18 octets
>01/08 10:36:04 beepd-re 1.wrap wrote 395 octets
>01/08 10:36:04 beepd-re 1.wrap wrote 1913 octets
>01/08 10:36:04 beepd-re 1.wrap wrote 353 octets
>[normal so far]
>01/08 10:36:04 beepd-re 2.wrap id=0 fd=6 revents=0x19/0x19
>01/08 10:36:04 beepd-re 0.wrap socket error: 6
>01/08 10:36:04 beepd-re 0.wrap stopping iostate: 6
>01/08 10:36:04 beepd-re 0.wrap deleting iostate: 6
>
>What is a socket error, and how can I prevent it or recover from it?
>
>I am also seeing problems with frames getting lost, I'm not quite sure 
>why yet but perhaps they are related.  The traffic is over a lightly 
>loaded 100TX network.
>
>>From the peer's perspective, I see messages like this:
>12/30 10:49:16 runberyl 2.wrap id=0 fd=5 revents=0x11/0x1
>12/30 10:49:16 runberyl 0.wrap socket error: 5
>12/30 10:49:16 runberyl 0.wrap stopping iostate: 5
>12/30 10:49:16 runberyl 0.wrap deleting iostate: 5
>12/30 10:49:29 runberyl 2.core start logging
>12/30 10:49:29 runberyl 0.wrap wrapper created: 5
>12/30 10:49:29 runberyl 1.wrap wrote 150 octets
>[...]
>12/30 10:49:29 runberyl 1.wrap wrote 15 octets
>12/30 10:49:29 runberyl 1.wrap read 16 octets
>12/30 10:49:50 runberyl 0.wrap wrapper destroyed: 5
>12/30 10:49:50 runberyl 0.wrap stopping iostate: 5
>12/30 10:49:50 runberyl 0.wrap deleting iostate: 5
>12/30 10:49:50 runberyl 2.core done logging
>
>
>
>
>-------------------------------------------------------
>-- David C. Niemi           Adeptech Systems, Inc.   --
>-- Reston, Virginia, USA    http://www.adeptech.com/ --
>-------------------------------------------------------
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Perforce Software.
>Perforce is the Fast Software Configuration Management System offering
>advanced branching capabilities and atomic changes on 50+ platforms.
>Free Eval! http://www.perforce.com/perforce/loadprog.html
>_______________________________________________
>Beepcore-c-users mailing list
>Bee...@li...
>https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
>
>

[Beepcore-c-users] Mysterious socket error

[David C N. <dc...@ad...>]

I am again working on my application built on beepcore-c (under Linux).  
I occasionally have BEEP sessions (or at least channels) just drop for no
apparent reason.  The log file shows this:

01/08 10:33:00 beepd-re 2.core start logging
01/08 10:33:00 beepd-re 2.wrap loaded profile for http://www.adeptech.com/beryllium/BERYL/RECEIVE
01/08 10:33:00 beepd-re 1.wrap duplicate library libberyl.so, continuing...
01/08 10:33:00 beepd-re 2.wrap loaded profile for http://www.adeptech.com/beryllium/BERYL/SEND
01/08 10:33:00 beepd-re 2.wrap listening on 5 (backlog 128)
01/08 10:33:32 beepd-re 0.wrap wrapper created: 6
01/08 10:33:32 beepd-re 1.wrap wrote 218 octets
01/08 10:33:32 beepd-re 1.wrap wrote 15 octets
01/08 10:33:33 beepd-re 1.wrap read 67 octets
[...]
01/08 10:36:04 beepd-re 1.wrap read 18 octets
01/08 10:36:04 beepd-re 1.wrap wrote 395 octets
01/08 10:36:04 beepd-re 1.wrap wrote 1913 octets
01/08 10:36:04 beepd-re 1.wrap wrote 353 octets
[normal so far]
01/08 10:36:04 beepd-re 2.wrap id=0 fd=6 revents=0x19/0x19
01/08 10:36:04 beepd-re 0.wrap socket error: 6
01/08 10:36:04 beepd-re 0.wrap stopping iostate: 6
01/08 10:36:04 beepd-re 0.wrap deleting iostate: 6

What is a socket error, and how can I prevent it or recover from it?

I am also seeing problems with frames getting lost, I'm not quite sure 
why yet but perhaps they are related.  The traffic is over a lightly 
loaded 100TX network.

From the peer's perspective, I see messages like this:
12/30 10:49:16 runberyl 2.wrap id=0 fd=5 revents=0x11/0x1
12/30 10:49:16 runberyl 0.wrap socket error: 5
12/30 10:49:16 runberyl 0.wrap stopping iostate: 5
12/30 10:49:16 runberyl 0.wrap deleting iostate: 5
12/30 10:49:29 runberyl 2.core start logging
12/30 10:49:29 runberyl 0.wrap wrapper created: 5
12/30 10:49:29 runberyl 1.wrap wrote 150 octets
[...]
12/30 10:49:29 runberyl 1.wrap wrote 15 octets
12/30 10:49:29 runberyl 1.wrap read 16 octets
12/30 10:49:50 runberyl 0.wrap wrapper destroyed: 5
12/30 10:49:50 runberyl 0.wrap stopping iostate: 5
12/30 10:49:50 runberyl 0.wrap deleting iostate: 5
12/30 10:49:50 runberyl 2.core done logging




-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------

[Beepcore-c-users] Os X

[Torsten R. <tor...@hi...>]

Moi,

awfully quit here, is there still anyone around ? Would love to hear 
some good news. I've spend the last month implementing one of our 
protocols using Beepy, pythons beep implementation, and that went well. 
Now for a c  server.

I got the cvs version to compile on Os X 10.3.2 with only minor tweaks:

I removed the cyrus-profiles compilation, it was referring to sasl.h, 
where is that ?

I hardcoded FREEBSD as threading model like
Index: threaded_os/utility/semutex.h
===================================================================
RCS file: /cvsroot/beepcore-c/beepcore-c/threaded_os/utility/semutex.h,v
retrieving revision 1.12
diff -r1.12 semutex.h
17a18
 > #define FREEBSD 1

Not pretty, but worked. Is there a way to pass that as configure option 
or for the configure to set that correctly ?

Lastly, it wasn't finding struct iovec correctly, so I did
Index: base/generic/CBEEP.h
===================================================================
RCS file: /cvsroot/beepcore-c/beepcore-c/base/generic/CBEEP.h,v
retrieving revision 1.2
diff -r1.2 CBEEP.h
28a29,30
 > #include <sys/types.h>
 > #include <unistd.h>

Best,

	Torsten

Re: [Beepcore-c-users] threading: is lock needed in pro_message_available

[William J. M. <wm...@es...>]

Events to be processed in a thread are posted to a queue for that
thread and that threads semaphoe is posted to wake it up if nead be, 
so the notify functions run in that thread.  The thread that does the 
adding to that queue is the wrapper's thread.

Good point on pro_close_confirmation...  it does in fact need to be 
synchronus.  Bother.  

Mark was working on a non-threaded wrapper, which has some fairly
major reorganization, but he did not complete it as the customer
stopped paying, and he's been doing other things since.

The openssl question....  probably a bug in fact, but all the IO is in fact
handled in the same thread so probably not a locking problem yet, but
definitely a gotcha if that changes.

-bill

On Wed, Dec 10, 2003 at 03:26:37PM -0800, Lei Zhang wrote:
> Actually my goal is not to make the wrapper more non-blocking. 
>  'pipelining' is not a good thing for the profile I'm developing.
> 
> With the thread management hidden so well in the wrapper, it's hard to 
> tell from which thread those profile callbacks are called - and if any 
> lock is needed to protect data structure such as PRO_LOCALDATA.  Even if 
> "it would be possible for a channel to maintain its own thread', the 
> pro_close_confirmation() still will get called from a thread other than 
> the thread of the channel's.  IIRC, somebody asked about the 
> availability of a non threaded wrapper months ago - is there such a 
> wrapper available now?
> 
> Another question: the openssl FAQ says: if the ssl library is to be used 
> in a MT application, a couple of CRYPTO_* functions should be called to 
> setup the ssl library locking mechanism.  But I don't see these CRYPTO_* 
> functions in beepcore-c - is it because all the socket I/O is handled by 
> a single thread, so that there is no need to do the CRYPTO_* setup?
> 
> Thanks,
> Lei
> 

Re: [Beepcore-c-users] threading: is lock needed in pro_message_available

[Lei Z. <lz...@ju...>]

Actually my goal is not to make the wrapper more non-blocking. 
 'pipelining' is not a good thing for the profile I'm developing.

With the thread management hidden so well in the wrapper, it's hard to 
tell from which thread those profile callbacks are called - and if any 
lock is needed to protect data structure such as PRO_LOCALDATA.  Even if 
"it would be possible for a channel to maintain its own thread', the 
pro_close_confirmation() still will get called from a thread other than 
the thread of the channel's.  IIRC, somebody asked about the 
availability of a non threaded wrapper months ago - is there such a 
wrapper available now?

Another question: the openssl FAQ says: if the ssl library is to be used 
in a MT application, a couple of CRYPTO_* functions should be called to 
setup the ssl library locking mechanism.  But I don't see these CRYPTO_* 
functions in beepcore-c - is it because all the socket I/O is handled by 
a single thread, so that there is no need to do the CRYPTO_* setup?

Thanks,
Lei

  Even if William J. Mills wrote:

>The way the C implementation works each profile may be instantiated
>as thread-per-channel or working in a common worker thread.  Events
>for a channel are queued in the work queue for that channel, with the
>shared work thread getting all events that odn't have thread-per-channel
>in the order that they are recieved.
>
>Your observation is correct, that the channel gets notifications sequentially
>and in most implementations it's doing the work itself.  It would be possible
>for a channel to maintain it's own thread, and simply enqueue events when
>the notify function is called, and could process them in a more non-blocking
>fashion.  Remembering of course that you are bound by the ordering restrictions
>for MSG processing.
>
>Does that help?
>
>-bill
>
>On Thu, Dec 04, 2003 at 11:57:33AM -0800, Lei Zhang wrote:
>
>>Howdy,
>>
>>I've been digging the wrapper code to no avail for answer to a simple 
>>question: it seems each incoming message gets delivered to the 
>>application via a different thread, should I use lock to protect 
>>critical section in pro_message_available?  Some testing shows that the 
>>application gets notified about an incoming message only after it has 
>>finished sending RPY to the previous message - is this observation wrong?
>>
>>Any hint is immensely appreciated.
>>Lei
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: SF.net Giveback Program.
>>Does SourceForge.net help you be more productive?  Does it
>>help you create better code?  SHARE THE LOVE, and help us help
>>YOU!  Click Here: http://sourceforge.net/donate/
>>_______________________________________________
>>Beepcore-c-users mailing list
>>Bee...@li...
>>https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
>>
>
>

Re: [Beepcore-c-users] threading: is lock needed in pro_message_available

[William J. M. <wm...@es...>]

The way the C implementation works each profile may be instantiated
as thread-per-channel or working in a common worker thread.  Events
for a channel are queued in the work queue for that channel, with the
shared work thread getting all events that odn't have thread-per-channel
in the order that they are recieved.

Your observation is correct, that the channel gets notifications sequentially
and in most implementations it's doing the work itself.  It would be possible
for a channel to maintain it's own thread, and simply enqueue events when
the notify function is called, and could process them in a more non-blocking
fashion.  Remembering of course that you are bound by the ordering restrictions
for MSG processing.

Does that help?

-bill

On Thu, Dec 04, 2003 at 11:57:33AM -0800, Lei Zhang wrote:
> Howdy,
> 
> I've been digging the wrapper code to no avail for answer to a simple 
> question: it seems each incoming message gets delivered to the 
> application via a different thread, should I use lock to protect 
> critical section in pro_message_available?  Some testing shows that the 
> application gets notified about an incoming message only after it has 
> finished sending RPY to the previous message - is this observation wrong?
> 
> Any hint is immensely appreciated.
> Lei
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

Re: [Beepcore-c-users] threading: is lock needed in pro_message_available

[Huston <hu...@us...>]

Lei,

From what I recall your observations are correct. It would take a bit of
looking to track this down because of how the synchronization/locking was
implemented.

--Huston

----- Original Message ----- 
From: "Lei Zhang" <lz...@ju...>
To: <bee...@li...>
Sent: Thursday, December 04, 2003 12:57 PM
Subject: [Beepcore-c-users] threading: is lock needed in
pro_message_available


> Howdy,
>
> I've been digging the wrapper code to no avail for answer to a simple
> question: it seems each incoming message gets delivered to the
> application via a different thread, should I use lock to protect
> critical section in pro_message_available?  Some testing shows that the
> application gets notified about an incoming message only after it has
> finished sending RPY to the previous message - is this observation wrong?
>
> Any hint is immensely appreciated.
> Lei
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
>
>

[Beepcore-c-users] threading: is lock needed in pro_message_available

[Lei Z. <lz...@ju...>]

Howdy,

I've been digging the wrapper code to no avail for answer to a simple 
question: it seems each incoming message gets delivered to the 
application via a different thread, should I use lock to protect 
critical section in pro_message_available?  Some testing shows that the 
application gets notified about an incoming message only after it has 
finished sending RPY to the previous message - is this observation wrong?

Any hint is immensely appreciated.
Lei

[Beepcore-c-users] flow control using SEQ

[Lei Z. <lz...@ju...>]

Hi,

I'd like to get some advice on how well beepcore-c does flow control. 
 I'm running into a deadlock - my profile listener often generates large 
amount of response data, I can see that the beep layer chops up the very 
long messages and sends out only 4k bytes at one time; then it seems to 
be waiting for a SEQ frame from the peer; the peer never sends back a 
SEQ - deadlock, nobody budges an inch.

None of the profiles provided in the library needs to send out large 
messages, so I'm wondering if this part of functionality was ever tested 
(absolutely no offense).

I'll dig more.  Any advice is greatly appreicated.
Lei

Re: [Beepcore-c-users] beepng: use TLS profile together with syslog raw profile

[William J. M. <wm...@es...>]

All channels are asked if they are willing to close before the
reset, then if all ok, then all are clsoed. then the tuning profile runs.
Once the tuning profile runs then the tuning reset complete callbacks are 
run.

There's no restriction on opening channels at any particular tuning level,
and nothing says you  can't do a "session resumption" logic within a profile
across tuning resets.  .

If there's a bug in the behavior of the syslog raw, or if it's right
and the wrapper logic is wrong, taht might cause this.

-bill


On Fri, Nov 14, 2003 at 04:48:15PM -0800, Lei Zhang wrote:
> William J. Mills wrote:
> 
> >You mean that if you run it with no other profiles, just TLS it hangs,
> >but if you include another profile like null, it works?
> >
> No, I mean TLS + null works, but TLS + syslog-raw hangs.  The null 
> channel is created after tuning reset is done by explicitly calling 
> null_start(); while the syslog-raw channel is created on answering 
> <greeting>.  I just tried this:
> 
> -  remove pro_greeting_notification from syslog-raw.c
> -  explicitly create syslog-raw channel in beepng.c after the tuning is done
> 
> Now beepd/beepng is happy.  Does the RFC say anything about all "data" 
> channels should only be started after the tuning reset is done?
> 
> Thanks,
> Lei
> 
> >
> >If so then there is probably a bug in the tuning reset code that
> >waits for all other profiles to answer the tuning reset request.
> >
> >-bill
> >
> >
> >On Fri, Nov 14, 2003 at 03:18:08PM -0800, Lei Zhang wrote:
> >
> >>Hi,
> >>
> >>I've been fooling around with beepcore-c for a couple of weeks.  It 
> >>works mostly as advertised until today I tried to run 'beepng -t 
> >><cert-file-name> -Z -p <port> localhost'.  beepd seems to be stuck at 
> >>the TLS profile pro_start_indication:
> >>
> >>TLS session_init: role='L' mode="plaintext"
> >>SR session_init: role='L' mode="plaintext"
> >>SR greeting_notification status=P
> >>SR start_indication: piggyback="<NULL>"
> >>SR callback_listener v=0x8071600 code=350
> >>   diagnostic="(null)"
> >>TLS start_indication: servername="localhost" piggyback="<ready />"
> >>SR tuning_reset_indication   <=== stuck here
> >>
> >>Running them with TLS profile and the null profile together works. 
> >> Anybody sees anything obvious here?
> >>
> >>Help immensely appreciate,
> >>Lei
> >>
> >>
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF. Net email is sponsored by: GoToMyPC
> >>GoToMyPC is the fast, easy and secure way to access your computer from
> >>any Web browser or wireless device. Click here to Try it Free!
> >>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> >>_______________________________________________
> >>Beepcore-c-users mailing list
> >>Bee...@li...
> >>https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
> >>
> >
> >
> 
> 
> 

Re: [Beepcore-c-users] beepng: use TLS profile together with syslog raw profile

[Lei Z. <lz...@ju...>]

William J. Mills wrote:

>You mean that if you run it with no other profiles, just TLS it hangs,
>but if you include another profile like null, it works?
>
No, I mean TLS + null works, but TLS + syslog-raw hangs.  The null 
channel is created after tuning reset is done by explicitly calling 
null_start(); while the syslog-raw channel is created on answering 
<greeting>.  I just tried this:

-  remove pro_greeting_notification from syslog-raw.c
-  explicitly create syslog-raw channel in beepng.c after the tuning is done

Now beepd/beepng is happy.  Does the RFC say anything about all "data" 
channels should only be started after the tuning reset is done?

Thanks,
Lei

>
>If so then there is probably a bug in the tuning reset code that
>waits for all other profiles to answer the tuning reset request.
>
>-bill
>
>
>On Fri, Nov 14, 2003 at 03:18:08PM -0800, Lei Zhang wrote:
>
>>Hi,
>>
>>I've been fooling around with beepcore-c for a couple of weeks.  It 
>>works mostly as advertised until today I tried to run 'beepng -t 
>><cert-file-name> -Z -p <port> localhost'.  beepd seems to be stuck at 
>>the TLS profile pro_start_indication:
>>
>>TLS session_init: role='L' mode="plaintext"
>>SR session_init: role='L' mode="plaintext"
>>SR greeting_notification status=P
>>SR start_indication: piggyback="<NULL>"
>>SR callback_listener v=0x8071600 code=350
>>   diagnostic="(null)"
>>TLS start_indication: servername="localhost" piggyback="<ready />"
>>SR tuning_reset_indication   <=== stuck here
>>
>>Running them with TLS profile and the null profile together works. 
>> Anybody sees anything obvious here?
>>
>>Help immensely appreciate,
>>Lei
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF. Net email is sponsored by: GoToMyPC
>>GoToMyPC is the fast, easy and secure way to access your computer from
>>any Web browser or wireless device. Click here to Try it Free!
>>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
>>_______________________________________________
>>Beepcore-c-users mailing list
>>Bee...@li...
>>https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
>>
>
>

Re: [Beepcore-c-users] beepng: use TLS profile together with syslog raw profile

[William J. M. <wm...@es...>]

You mean that if you run it with no other profiles, just TLS it hangs,
but if you include another profile like null, it works?

If so then there is probably a bug in the tuning reset code that
waits for all other profiles to answer the tuning reset request.

-bill


On Fri, Nov 14, 2003 at 03:18:08PM -0800, Lei Zhang wrote:
> Hi,
> 
> I've been fooling around with beepcore-c for a couple of weeks.  It 
> works mostly as advertised until today I tried to run 'beepng -t 
> <cert-file-name> -Z -p <port> localhost'.  beepd seems to be stuck at 
> the TLS profile pro_start_indication:
> 
> TLS session_init: role='L' mode="plaintext"
> SR session_init: role='L' mode="plaintext"
> SR greeting_notification status=P
> SR start_indication: piggyback="<NULL>"
> SR callback_listener v=0x8071600 code=350
>    diagnostic="(null)"
> TLS start_indication: servername="localhost" piggyback="<ready />"
> SR tuning_reset_indication   <=== stuck here
> 
> Running them with TLS profile and the null profile together works. 
>  Anybody sees anything obvious here?
> 
> Help immensely appreciate,
> Lei
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

[Beepcore-c-users] beepng: use TLS profile together with syslog raw profile

[Lei Z. <lz...@ju...>]

Hi,

I've been fooling around with beepcore-c for a couple of weeks.  It 
works mostly as advertised until today I tried to run 'beepng -t 
<cert-file-name> -Z -p <port> localhost'.  beepd seems to be stuck at 
the TLS profile pro_start_indication:

TLS session_init: role='L' mode="plaintext"
SR session_init: role='L' mode="plaintext"
SR greeting_notification status=P
SR start_indication: piggyback="<NULL>"
SR callback_listener v=0x8071600 code=350
   diagnostic="(null)"
TLS start_indication: servername="localhost" piggyback="<ready />"
SR tuning_reset_indication   <=== stuck here

Running them with TLS profile and the null profile together works. 
 Anybody sees anything obvious here?

Help immensely appreciate,
Lei

Re: [Beepcore-c-users] BEEPD clashes in Solaris 2.6

[William J. M. <wm...@es...>]

Excellent!  Probably the next to-do then is to 
disable POSIX threads on that platform and only use native.

Regards,

-bill

On Wed, Nov 05, 2003 at 12:12:47PM +0800, Guan Wee LOO wrote:
> Hi 
> My mistake, you are right. It seems to work fine with the native thread
> library of SUNOS instead of the POSIX thread library. Thank you.
> 
> Regards,
> Guan Wee
> 
> -----Original Message-----
> From: Guan Wee LOO 
> Sent: Monday, November 03, 2003 4:15 PM
> To: 'William J. Mills'
> Cc: bee...@li...
> Subject: RE: [Beepcore-c-users] BEEPD clashes in Solaris 2.6
> 
> 
> Hi,
> Thanks for the suggestion. Now I simply use the pthread library instead
> of the native thread library. However I still feel that the wrapper
> codes are not really stable. 
> 
> 
> Guan Wee
> 
> -----Original Message-----
> From: William J. Mills [mailto:wm...@es...] 
> Sent: Saturday, November 01, 2003 5:21 AM
> To: Guan Wee LOO
> Cc: bee...@li...
> Subject: Re: [Beepcore-c-users] BEEPD clashes in Solaris 2.6
> 
> 
> There might be a couple of different threading options on Solaris. The
> code used to compile there, but I am not sure if anyone has in 
> a while.  Can you see what threading you have available and perhaps
> reconfigure to native from posix threads for example?  This might solve
> it.
> 
> -bill
> 
> 
> On Fri, Oct 31, 2003 at 03:51:42PM +0800, Guan Wee LOO wrote:
> > Hi,
> > I  managed to compiled the BEEPCORE-c implementation and its beepd
> > sample listener program (but only after disabling the logging feature,
> 
> > can anyone tell me how without doing this?).  Initially, everything 
> > seemed fine but the program hanged and crashed after about the 4th 
> > BEEP connection (from a BEEP client using the echo profile).  I am 
> > testing with the null-echo profile that comes with the samples. It 
> > seems that the problem lies with the SEM_WAIT call in the 
> > fiostate_unblock_write function (bp_fiostate.c)- it hangs at this 
> > point. I am using the libposix4 library. Is there anyone who manage to
> 
> > compile and run the samples successfully in Solaris 2.x without 
> > encountering any problem? Please let me know. Thanks.
> >  
> > Regards,
> > Guan Wee

RE: [Beepcore-c-users] BEEPD clashes in Solaris 2.6

[Guan W. L. <gua...@ap...>]

Hi=20
My mistake, you are right. It seems to work fine with the native thread
library of SUNOS instead of the POSIX thread library. Thank you.

Regards,
Guan Wee

-----Original Message-----
From: Guan Wee LOO=20
Sent: Monday, November 03, 2003 4:15 PM
To: 'William J. Mills'
Cc: bee...@li...
Subject: RE: [Beepcore-c-users] BEEPD clashes in Solaris 2.6


Hi,
Thanks for the suggestion. Now I simply use the pthread library instead
of the native thread library. However I still feel that the wrapper
codes are not really stable.=20


Guan Wee

-----Original Message-----
From: William J. Mills [mailto:wm...@es...]=20
Sent: Saturday, November 01, 2003 5:21 AM
To: Guan Wee LOO
Cc: bee...@li...
Subject: Re: [Beepcore-c-users] BEEPD clashes in Solaris 2.6


There might be a couple of different threading options on Solaris. The
code used to compile there, but I am not sure if anyone has in=20
a while.  Can you see what threading you have available and perhaps
reconfigure to native from posix threads for example?  This might solve
it.

-bill


On Fri, Oct 31, 2003 at 03:51:42PM +0800, Guan Wee LOO wrote:
> Hi,
> I  managed to compiled the BEEPCORE-c implementation and its beepd
> sample listener program (but only after disabling the logging feature,

> can anyone tell me how without doing this?).  Initially, everything=20
> seemed fine but the program hanged and crashed after about the 4th=20
> BEEP connection (from a BEEP client using the echo profile).  I am=20
> testing with the null-echo profile that comes with the samples. It=20
> seems that the problem lies with the SEM_WAIT call in the=20
> fiostate_unblock_write function (bp_fiostate.c)- it hangs at this=20
> point. I am using the libposix4 library. Is there anyone who manage to

> compile and run the samples successfully in Solaris 2.x without=20
> encountering any problem? Please let me know. Thanks.
> =20
> Regards,
> Guan Wee

RE: [Beepcore-c-users] BEEPD clashes in Solaris 2.6

[Guan W. L. <gua...@ap...>]

Hi,
Thanks for the suggestion. Now I simply use the pthread library instead
of the native thread library. However I still feel that the wrapper
codes are not really stable.=20


Guan Wee

-----Original Message-----
From: William J. Mills [mailto:wm...@es...]=20
Sent: Saturday, November 01, 2003 5:21 AM
To: Guan Wee LOO
Cc: bee...@li...
Subject: Re: [Beepcore-c-users] BEEPD clashes in Solaris 2.6


There might be a couple of different threading options on Solaris. The
code used to compile there, but I am not sure if anyone has in=20
a while.  Can you see what threading you have available and perhaps
reconfigure to native from posix threads for example?  This might solve
it.

-bill


On Fri, Oct 31, 2003 at 03:51:42PM +0800, Guan Wee LOO wrote:
> Hi,
> I  managed to compiled the BEEPCORE-c implementation and its beepd=20
> sample listener program (but only after disabling the logging feature,

> can anyone tell me how without doing this?).  Initially, everything=20
> seemed fine but the program hanged and crashed after about the 4th=20
> BEEP connection (from a BEEP client using the echo profile).  I am=20
> testing with the null-echo profile that comes with the samples. It=20
> seems that the problem lies with the SEM_WAIT call in the=20
> fiostate_unblock_write function (bp_fiostate.c)- it hangs at this=20
> point. I am using the libposix4 library. Is there anyone who manage to

> compile and run the samples successfully in Solaris 2.x without=20
> encountering any problem? Please let me know. Thanks.
> =20
> Regards,
> Guan Wee