Linux-Development-Apps Digest #414, Volume #7 Fri, 18 May 01 06:13:12 EDT
Contents:
Re: catch 22 in SysV semaphores (Greg Copeland)
Re: Asynchronous sockets (Greg Copeland)
Re: Asynchronous sockets (Greg Copeland)
Re: SIGSEGV is not blocking (Robert Redelmeier)
Re: A linuxthreads C++ object question (David Konerding)
Re: SIGSEGV is not blocking
Re: Which GUI tool kit to use? ("D. Stimits")
Re: Faster than strstr (Brian Inglis)
Re: writing to syslog
Re: PostgreSQL_question
Re: Which GUI tool kit to use? (Rolf Magnus)
Re: Cross compiling from Windows to Linux (Sergei Organov)
Re: Asynchronous sockets (John Forkosh)
Re: losing stdout after SIGINT (Villy Kruse)
Re: SIGSEGV is not blocking (Kasper Dupont)
Re: How do I make a messagebox?? (John Thompson)
----------------------------------------------------------------------------
Crossposted-To: comp.unix.programmer
Subject: Re: catch 22 in SysV semaphores
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 17 May 2001 21:23:15 -0500
The distinction that you are making is what people normally refer to as
mutex and event semaphores. The difference is easy to understand. Event
semaphores are used to signal that is, to create a synchronization point
for one or more processes. The mutex is used to restrict (serialize)
access to a resource. The idea is that one process will create the event
semaphore while the other processes do whatever it is they need to do.
Once they are all ready to move forward, they wait on the event semaphore.
When all processes have signaled they are ready (via the event semaphore),
all processes continue at the same time. Now then, if at all possible,
simply have one process create all of your resources and be done with it.
If you are using SYS V IPC, the keys can be passed from process to
process and even from execution to execution without having to recreate
the resources in question. This approach, depending on what you are
trying to do can often, greatly simplify things for you.
Greg
"Bill Medland" <[EMAIL PROTECTED]> writes:
> I was just testing some code using System V IPC sempahores as mutexes and
> thought "but what if.." and it bit me. Clearly I am misunderstanding
> something.
>
> I have some code that gets a set of 10 semaphores (using semget) and uses
> them to provide mutexes between two processes. Having got the semaphores I
> initialise them to 1 using semctl so that I can use them as mutexes by
> using semop to decrement by 1.
>
> It all works nicely except that if a second process goes through that
> initialisation while the first process has one of the mutexes the second
> process destroys the capability (by changing the 0 to 1) and is able also
> to "get the mutex".
>
> How am I supposed to ensure that the semaphores only get set to 1 once?
>
> Bill
>
> (The code is basically as one finds in e.g "Beginning Linux Programming"
> except such examples tend to "leave the problem of who initialises as an
> exercise for the student")
>
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
Subject: Re: Asynchronous sockets
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 17 May 2001 21:26:35 -0500
Some people consider the use of select() to be an asynchronous I/O model.
Not to long ago, someone pointed me toward SGI's Open Source web site.
They have been working on AIO for Linux. I do not if it is currently
limited to file I/O or supports all fds. Nonetheless, work is underway
here. See if that will work for you.
Greg
"Boris" <[EMAIL PROTECTED]> writes:
> "Kristian Kismul" <[EMAIL PROTECTED]>,
> news:5pFG6.1490$[EMAIL PROTECTED]...
> > I'm in need of information on how to work with asynchronous sockets in
> > BSD-sock under Linux. Any help / code examples / url's / book suggestions
> > are very welcome!
>
> Do you mean asynchronous I/O model? I'm not sure if this is supported on
> Linux - is it?
>
> Boris
>
>
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
Subject: Re: Asynchronous sockets
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 17 May 2001 21:38:44 -0500
[EMAIL PROTECTED] (David Konerding) writes:
>
> As for 'asynchronous I/O' not being supported on linux-- I think what's meant by
> that type of a i/o is that the program that wants to read from a socket just sets up
> a "handler function" which is called by the OS when the I/O is ready. It's arguable
> whether this is a superior technique to select, but some people swear by it
>(especially
> people who are trying to defend NT's superiority to linux :-)
Actually, it's pretty well accepted that the I/O model you are describing tends to
scale
*MUCH* better and perform slightly faster on a heavily loaded system; assuming that it
has been implemented well. SGI's AIO implementation specifically noted that they got
20% better database performance versus synchronous buffered I/O. Please keep in mind
that SGI's implementation is still under development, however, if they are seeing 20%
in initial development, I think that tends to support that serious rewards can be
achieved by chasing this rabbit.
The reasons are very well known and accepted. In fact, it is so well understood, this,
in part, is *some* of the reasons why /dev/poll came to be. In short, select has a lot
of overhead when working with large numbers of fd's as well as having some serious
limits when working with large fd sets. I hope you understand that select is not an
end-all, do-all, perfect function. In fact, lots of people prefer poll(), which, if
memory serves, Linux's select() implementation is implemented using poll(). Again,
AIO still has some advantages of scale over both poll() and select() because of how
they have to be implemented.
One last note, IMOHO, Microsoft's support of AIO in almost all facets of the kernel
was one of the few things that they did correct. It works and it works well.
Greg
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
Date: Thu, 17 May 2001 21:54:41 -0500
From: Robert Redelmeier <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.system,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
[EMAIL PROTECTED] wrote:
>
> Robert Redelmeier <[EMAIL PROTECTED]> wrote:
>
> >It could be worse than that. The continuously generated interrupt
> >could prevent the scheduler from ever running, and the machine would
> >be effectively locked-up.
>
> But it's a trap not an interrupt. The timer interrupt should still
> get serviced.
On i386 a trap _is_ an interrupt. The only difference is
the pushed IP corresponds to the faulting instruction, not
the next instruction. This greatly facilitates re-start.
When an int is executed, hardware disables all other ints.
The ISR (OS) may re-enable interrupts (or not). Usually
it will, but for some critical code, it cannot.
-- Robert
------------------------------
From: [EMAIL PROTECTED] (David Konerding)
Subject: Re: A linuxthreads C++ object question
Date: 18 May 2001 02:22:08 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 18 May 2001 01:33:14 +0100, Neil Butterworth <[EMAIL PROTECTED]>
wrote:
>>
>> Right. The above behavior of STLport is due to its use of the SGI STL
> library
>> and only then when you use shared containers.
>
> You mean the stream library?
>
>> What I meant was that the base
>> standard libray (strings, streams, streambufs, etc) are protected in
> STLport.
>
> Not in the way you seem to think they are. See the SGI site for their thread
> safety guarantee, which is more or less identical to the abreviated STLport
> version I posted.
Aha, OK, I see then, the restriction is only when two threads use the same
object instances. In my model, all usage of STL and the standard library
is to thread-specific objects.
>
>> I would have thought the STL components to be as well, but apparently they
> aren't.
>> I don't use the model of sharing containers between threads.
>
> But this is very common. Having an input queue which multiple service
> threads access is the way that almost all server apps are written. And if
> you have such a an architecture, you need to protect the queue with some
> sort of lock.
Yes. I'm actually doing this. But, the threads are all Python
threads, python threads on Linux uses pthreads. The python threads
sometime call into C++, either into OmniORB (which I'm using as the
CORBA implementation), or our own application. I share data between
threads at the Python layer using threading.Queue, a python class which
implements thread safe FIFO. There are versions of this which work
with many consumer threads.
>
>> I'm pretty certain
>> that the user can use all the standard library except for STL without
> worrying--
>> if that's not true, then I've got to get rid of a certain basic assumption
> I'm making.
>
> Yes, you do. The guarantee I posted (basically, if a container is modified
> in any way by a method, that method cannot be called safely ON THE SAME
> OBJECT from multiple threads) is common to all Standard C++ Library
> implementations that I'm aware of.
>
>> I certainly would not want to have to do a lock or mutex around every
> string I construct
>> or stream I access.
>
> But you don't! That's not what I or the library suppliers are saying at all.
> Read the STLport guarantee again. It doesn't mention construction at all.
> OTOH, if you have multiple threads accessing the same stream, then you _do_
> have a potential problem.
Does that include cout and cerr?
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: comp.os.linux.development.system,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Fri, 18 May 2001 03:28:52 -0000
In article <[EMAIL PROTECTED]>, Robert Redelmeier <[EMAIL PROTECTED]> wrote:
>> But it's a trap not an interrupt. The timer interrupt should still
>> get serviced.
>On i386 a trap _is_ an interrupt.
No, it isn't. A trap is caused by an instruction execution that fails
in some way. In other words a traps is a synchronous event while an
interrupt is a response to an external event. The difference is subtle
but it is a difference.
------------------------------
Date: Thu, 17 May 2001 21:43:39 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Which GUI tool kit to use?
Travis Stevens wrote:
>
> Hello all, hope you are doing well.
>
> I have never done GUI programming for linux (except Java.) I would like
> to write a C++ program (a game) with a GUI front end. Does anyone have
> any suggestions on which tool kit I should use, and why?
>
> Thank you
> -Trav
If you do any 3D rendering, you might try gtkglarea, basically a gtk
extension for OpenGL rendering.
D. Stimits, [EMAIL PROTECTED]
------------------------------
Subject: Re: Faster than strstr
From: Brian Inglis <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.c.moderated,comp.lang.c
Date: 18 May 2001 03:47:21 GMT
On 14 May 2001 19:53:09 GMT, Jerry Coffin <[EMAIL PROTECTED]>
wrote:
>In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>
>[ ... ]
>
>> Recent implementations should contain Boyer-Moore-Pratt searches
>> which use end first matching and a couple of arrays containing
>> skip offsets when unmatched and matched characters are seen to
>> run an order of magnitude faster than straight [split intended]
>> forward searches on single/multiple targets.
>
>Just FWIW, I know of:
>
>Knuth-Morris-Pratt
>Boyer-Moore
>Boyer-Moore-Horspool
>Sunday's variant of Boyer-Moore-Horspool
>
>but TTBOMK, Pratt was not involved in any variant on the Boyer-Moore
>search algorithm. I suppose to be complete, I could mention that
>I've invented another variant of Boyer-Moore that I believe is
>original, but isn't on the list above. I'm pretty sure Pratt didn't
>have anything to do with it either though. <G>
Just saw Boyer-Moore-Gosper mentioned recently -- will have to
look that one up!
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
[EMAIL PROTECTED] (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED]
spam traps
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: writing to syslog
Date: Fri, 18 May 2001 04:13:44 -0000
In article <[EMAIL PROTECTED]>,
Steve Connet <[EMAIL PROTECTED]> wrote:
>My app can't use LOG_LOCALx as the facility can it? I mean I haven't
>tried, but the docs say those are 'reserved for internal use' only.
No, it says they are reserved for *local* use. Go ahead and use one.
--
http://www.spinics.net/linux
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: PostgreSQL_question
Date: Fri, 18 May 2001 04:17:12 -0000
In article <[EMAIL PROTECTED]>,
Jorge Escalante <[EMAIL PROTECTED]> wrote:
>It worked, I could use the command 'su postgres'. Now, it is asking me for the
>password, and I don't have a clue what it is!
There isn't one. Become root first and then su to postgres.
--
http://www.spinics.net/linux
------------------------------
From: Rolf Magnus <[EMAIL PROTECTED]>
Subject: Re: Which GUI tool kit to use?
Date: Fri, 18 May 2001 08:56:26 +0200
D. Stimits wrote:
> Travis Stevens wrote:
>>
>> Hello all, hope you are doing well.
>>
>> I have never done GUI programming for linux (except Java.) I would like
>> to write a C++ program (a game) with a GUI front end. Does anyone have
>> any suggestions on which tool kit I should use, and why?
>>
>> Thank you
>> -Trav
>
> If you do any 3D rendering, you might try gtkglarea, basically a gtk
> extension for OpenGL rendering.
If you want C++, you can also use Qt, which includes QGLWidget.
------------------------------
From: Sergei Organov <[EMAIL PROTECTED]>
Subject: Re: Cross compiling from Windows to Linux
Date: 18 May 2001 10:42:34 +0400
"Bill Medland" <[EMAIL PROTECTED]> writes:
> Sergei Organov <[EMAIL PROTECTED]> wrote in article
> <[EMAIL PROTECTED]>...
> >
> > The fact that unlike Windows Linux is multi-user may help.
> >
> -snip
> > may have troubles with CR/LF and LF conventions for end-of-line in DOS
> and
> > UNIX. Try to configure Samba so that the same files on Samba share were
> seen
> > from Windows as DOS text and from Linux as Unix text, -- I recall it's
> > possible.
>
> I'd appreciate the details! (My reading of FAQ 1 at samba.org suggests
> that it isn't).
Then it isn't :-( But you can still copy to another location with simultaneous
CR/LF->LF conversion as a first step in building process on Linux as others
suggested.
>
> snip-
------------------------------
From: [EMAIL PROTECTED] (John Forkosh)
Subject: Re: Asynchronous sockets
Date: 18 May 2001 07:16:19 GMT
Greg Copeland ([EMAIL PROTECTED]) wrote:
: [EMAIL PROTECTED] (David Konerding) writes:
: >
: > As for 'asynchronous I/O' not being supported on linux-- I think what's meant by
: > that type of a i/o is that the program that wants to read from a socket just sets
:up
: > a "handler function" which is called by the OS when the I/O is ready. It's
:arguable
: > whether this is a superior technique to select, but some people swear by it
:(especially
: > people who are trying to defend NT's superiority to linux :-)
: Actually, it's pretty well accepted that the I/O model you are describing tends to
:scale
: *MUCH* better and perform slightly faster on a heavily loaded system; assuming that
:it
: has been implemented well.
<snip>
: One last note, IMOHO, Microsoft's support of AIO in almost all facets of the kernel
: was one of the few things that they did correct. It works and it works well.
Note that VMS also uses asynchronous i/o, which (also imoho) is a
pleasure to program with.
John ([EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: losing stdout after SIGINT
Date: 18 May 2001 07:27:03 GMT
On Thu, 17 May 2001 15:41:15 -0500,
Clifton T. Sharp Jr. <[EMAIL PROTECTED]> wrote:
>
>Another weirdness: I wasn't aware that the first signal is supposed to
>reset the signal vector, so originally I didn't manually reset it; but
>my program got SIGIO after SIGIO and never missed a beat.
>
Current version of glibc implements BSD style signals, regardless of
what the manual says. This, among other things, means the signal
handler will stay installed when a signal is caught, and certain
system calls will be automatically restarted rather than return
with a EINTR error.
Villy
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.system,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Fri, 18 May 2001 09:00:50 +0000
Steve Kirkendall wrote:
>
> "Michael J. Saletnik" wrote:
> >
> > David Schwartz <[EMAIL PROTECTED]> writes:
> >
> > > You say it ought to "work". What do you mean? What behavior would
> > > constitute working? You have left no reasonable thing for the
> > > implementation to do.
> >
> > If I explicitly block the SIGSEGV from being delivered, I would not
> > expect the process still to terminate on a SIGSEGV.
>
> As I understand it, "blocking" only means you can't get one SIGSEGV
> while executing the handler function for an earlier SIGSEGV. Outside
> of the handler function, the signal can still arrive.
>
> Try a plain old "signal(SIGSEGV, SIG_IGN)" call instead. You'll still
> have the issue of undefined behavior after ignoring a segmentation
> violation, but at least it'll still be doing... something.
It is possible for a process to block signals it
want to handle at a later time. In this case the
kernel will hold back the signal until it is
unblocked and then immediately deliver the signal.
The blocking can happen when a signal is being
delivered to prevent the next signal to be
delivered before the first has finished, but it
can also be done explicitly using the sigprocmask
system call.
--
Kasper Dupont
------------------------------
From: John Thompson <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.x
Subject: Re: How do I make a messagebox??
Date: Thu, 17 May 2001 21:02:35 -0500
Cam Stobbe wrote:
> Does Linux have a function that is equivalent or similar to the
> MessageBox in Windows?
>
> I am coding a simple application in C. It will not have a full-blown
> GUI. I just want to throw up a message box.
>
> I am using RedHat 6.2.
Have you looked at "xmessage?" It should be part of the
X11R6-contrib package on your system:
XMESSAGE(1) XMESSAGE(1)
NAME
xmessage - display a message or query in a window (X-based
/bin/echo)
SYNOPSIS
xmessage [ -buttons label1[:value1],label2[:value2], ...
] [ options ] -file filename
xmessage [ -buttons label1[:value1],label2[:value2], ...
] [ options ] message ...
DESCRIPTION
The xmessage program displays a window containing a mes
sage from the command line, a file, or standard input.
Along the lower edge of the message is row of buttons;
clicking the left mouse button on any of these buttons
will cause xmessage to exit. Which button was pressed is
returned in the exit status and, optionally, by writing
the label of the button to standard output.
...and so on...
--
-John ([EMAIL PROTECTED])
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.apps newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-Apps Digest
******************************
