Hi!
Is't needed to clear previous dl errors before new dlopen, dlsym, dlclose call?
See attach test programs.
$ gcc -shared -o demo.dll demo.c
$ gcc -shared -o demo2.dll demo2.c
$ gcc -o test test.c
$ ./test
Output:
handle = f2
dlsym init_plugin fail
init_plugin = 0
handle2 = f2
dlsym
After consolidating all of the lock code into a refresh method,
I realized that there are some pretty big races in the group/passwd
code. You can't just protect the reading of the buffers against
multiple access, you have to protect all operations which manipulate
the passwd/group buffers since
Christopher Faylor wrote:
Also, implying that there is a one-to-one correspondence between my
ChangeLog entries and the ones for your patches is a little simplistic.
It would be, but I never compared them. I only remarked that this
became one of your largest recent projects (in terms of
Christopher Faylor wrote:
After consolidating all of the lock code into a refresh method,
I realized that there are some pretty big races in the group/passwd
code. You can't just protect the reading of the buffers against
multiple access, you have to protect all operations which manipulate
Hi Jason,
On Fri, Jan 17, 2003 at 02:28:53PM -0500, Jason Tishler wrote:
Attached is a patch that implements nanosleep() by attempting to
reuse the current sleep() implementation which seems to provide the
necessary functionality.
I'm not sure if there is a better way to convey the fact
On Tue, Jan 21, 2003 at 04:58:42PM +0100, Corinna Vinschen wrote:
Hi Jason,
On Fri, Jan 17, 2003 at 02:28:53PM -0500, Jason Tishler wrote:
Attached is a patch that implements nanosleep() by attempting to
reuse the current sleep() implementation which seems to provide the
necessary
On Tue, Jan 21, 2003 at 10:39:00AM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
You had no comments on my last observation, MS doesn't raise an event
on mv and rm.
I'll tell you why I had no comment on this if you tell me why you had
no comment on the fact that I'd indicated I was
On Tue, Jan 21, 2003 at 10:53:29AM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
This has been there forever, I would not delay the release of 1.3.19
Did I say I was delaying anything?
By the way, I wrote the internal_get{pw,gr} routines having in mind
that they could be extended to
On Tue, Jan 21, 2003 at 11:02:01AM -0500, Christopher Faylor wrote:
On Tue, Jan 21, 2003 at 04:58:42PM +0100, Corinna Vinschen wrote:
I'm wondering if we could do without an extra function sleep_worker()
and let nanosleep() be the basic implementation. So sleep() as well
as usleep() could
On Tue, Jan 21, 2003 at 10:39:00AM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
You had no comments on my last observation, MS doesn't raise
an event
on mv and rm.
I'll tell you why I had no comment on this if you tell me why you had
no comment on the fact that I'd indicated I
On Tue, Jan 21, 2003 at 11:47:35AM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
You'd need a per-thread buffer to accomplish that. I assume that
is what you had in mind.
If you look at them, most internal_get{pw,gr} calls from outside
of passwd.cc and grp.cc only want the
Corinna,
Chris,
Thanks for your feedback.
On Tue, Jan 21, 2003 at 05:17:06PM +0100, Corinna Vinschen wrote:
On Tue, Jan 21, 2003 at 11:02:01AM -0500, Christopher Faylor wrote:
On Tue, Jan 21, 2003 at 04:58:42PM +0100, Corinna Vinschen wrote:
I'm wondering if we could do without an extra
On Tue, Jan 21, 2003 at 01:05:36PM -0500, Jason Tishler wrote:
Regarding usleep(), I was afraid to change it to use nanosleep() (aka
sleep_worker()) because its implementation was different than sleep().
I think usleep's implementation was incorrect, actually.
cgf
On Tue, Jan 21, 2003 at 01:05:25PM -0500, Christopher Faylor wrote:
On Tue, Jan 21, 2003 at 01:05:36PM -0500, Jason Tishler wrote:
Regarding usleep(), I was afraid to change it to use nanosleep() (aka
sleep_worker()) because its implementation was different than sleep().
I think usleep's
On Tue, Jan 21, 2003 at 04:16:49PM -0500, Jason Tishler wrote:
On Tue, Jan 21, 2003 at 01:05:25PM -0500, Christopher Faylor wrote:
I think usleep's implementation was incorrect, actually.
See attached for my next version which addresses the above too.
2003-01-21 Jason Tishler [EMAIL
On Tue, Jan 21, 2003 at 04:33:41PM -0500, Jason Tishler wrote:
On Tue, Jan 21, 2003 at 04:16:49PM -0500, Jason Tishler wrote:
On Tue, Jan 21, 2003 at 01:05:25PM -0500, Christopher Faylor wrote:
I think usleep's implementation was incorrect, actually.
See attached for my next version which
On Tue, Jan 21, 2003 at 11:47:35AM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
You'd need a per-thread buffer to accomplish that. I assume that is
what you had in mind.
If you look at them, most internal_get{pw,gr} calls from outside of
passwd.cc and grp.cc only want the {u,g}id,
On Tue, Jan 21, 2003 at 06:42:25PM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
Btw, Pierre, can you explain the rationale behind the check parameter
that some of the internal_* functions take? Why would you not want to
check for an up-to-date /etc/passwd or /etc/group?
Two
18 matches
Mail list logo
