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 init
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 Chang
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 manip
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 func
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
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() cou
Christopher Faylor wrote:
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 fa
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, the sid or the name,
but never the other fields.
I wanted to av
> 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 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 extr
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
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 <[EMAI
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
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,
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 reasons:
1) "check" is only true when the internal functions
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/g
The attached program ratchets through the bitrates defined in termios.h and
tests a given (as first argument) serial port. This test will indicate if
tcsetattr() returns an error when invalid bitrates are attempted on a given
serial port (along with perror() to print the error-message associated w
22 matches
Mail list logo
